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This  thesis  considers  the  design  and  uses  of  a  data 
dictionary  within  the  FOCUS  DBMS  package.  The  thesis 
details  the  background  and  design  considerations  of  an 
application  program  -for  the  Director  of  Admissions  at  the 
Naval  Postgraduate  School.  The  program  will  aid  in  the 
assignment  of  an  Academic  Profile  Code  <APC)  for  newly 
commissioned  Naval  Officers.  A  data  dictionary  is  designed 
and  implemented,  and  its  use  during  application  program 
development  is  discussed.  Features  from  commercial  DBMSs, 
fourth  generation  languages,  and  data  dictionaries  are 
compared  and  their  impact  on  information  systems  considered. 
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I.  ASSIGNMENT  QF  ACADEMIC  PROFILE  CODES  AT  THE  NAVAL 
POSTGRADUATE  SCHOOL 

A.   BACKGROUND 

At  the  Naval  Postgraduate  School  <NPS) ,  the  Director  of 
Admissions  is  tasked  with  evaluating  every  newly 
commissioned  Naval  Officer  concerning  eligibility  -for 
postgraduate  education.  The  evaluation  process  uses 
information  contained  in  undergraduate  transcripts  to 
compute  a  quality  point  rating  (QPR) .  In  addition,  course 
subject  areas  are  considered  before  the  assignment  of  an 
academic  profile  code  (APC) .  Approximately  3000-5000 
transcripts  are  processed  annually  by  hand. 

The  APC  is  a  three  digit  code  that  reflects  an 
individual's  QPR  as  well  as  background  in  specific 
mathematical  and  scientific  areas.  The  first  digit  of  the 
APC  is  derived  from  Table  I.  The  second  digit  is  the 
mathematics  code  and  is  based  on  the  criteria  in  Table  II. 
The  third  digit  is  the  science/engineering  code  and  is  based 
on  information  in  Table  III. 

The  Director  of  Admissions  at  NPS  feels  that  the  APC 
system  is  a  good  representation  of  a  student's  technical 
ability,   but   does   not   adequately   consider  non-technical 
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+- 

I 

+- 

I 


I 

I 
I 
I 
I 

+- 


TABLE  I 

FIRST  DIGIT  OF  AN  APC 

+ 

I  QPR  RANGE 


CODE 


0 
1 
2 
3 
4 
5 


>  . 


3.60-4.00 
3.20-3.59 
2.60-3. 19 
2.20-2.59 
1.90-2. 19 
0-1.89 


subject  areas.   It  is  conceivable  that  a  fourth  digit   might 
be  added  that  reflects  non-technical  performance. 

B.  OBJECTIVE 

FOCUS  has  been  selected  as  the  Data  Base  Management 
System  (DBMS)  for  NPS.  It  is  the  objective  of  this  thesis 
to  discuss  the  design  of  a  FOCUS  data  dictionary  and 
evaluate  its  use  during  the  development  of  an  application 
program  to  aid  in  the  assignment  of  APCs. 

C.  METHODOLOGY 

Despite  the  fact  that  the  DBMS  for  this  application 
was  chosen  in  advance,  this  thesis  will  compare  data  base 
models  and  explore  features  from  numerous  commercial 
systems.   It  will  also  look  at  the  concept  of   dependent  and 
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independent  data  dictionaries.   A  basic  data  dictionary  will 
be  designed  and   implemented  to   aid  in   the  development   of 


TABLE  II 

SECOND  DIGIT  OF  AN  APC 

i + 

CODE  !  MEANING 


Significant  post-calculus  math 
with  B  or  better  average 


Calculus  sequence  completed 
with  B+  or  better  average 


I  Calculus  sequence  completed 
!  with  average  between  C+  and  B 

H 


!  Two  or  more  pre-calculus 

1  courses  with  B  or  better 

i  average  or  one  calculus  course 

I  with  C  or  better  grade 


!  Two  or  more  pre-calculus 

I  courses  with  average  between 

I  B-  and  C+ 

■+ 


One  pre-calculus  course  with  C 
or  better  grade 


!  No  college-level  math  with  C 

!  or  better  grade 

.+ 


FOCUS  applications.   Design  considerations,  within  the  FOCUS 
environment,  Are       identified   for   the   dictionary   and   APC 
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application  program.   An  evaluation   of  the  usefulness  of   a 
dependent  data  dictionary  during  system  design  will  be  made. 


TABLE  III 

THIRD  DIGIT  OF  AN  APC 

+ 

CODE  I  MEANING 


0  !  Significant  upper  division 

!  technical  courses  with  B+  or 
I  better  average 

+ 


Significant  upper  division 
technical  courses  with  average 
between  C+  and  B 


I  Completed  calculus-based 
I  physics  sequence  with  B+  or 
!  better  average 


Completed  calculus-based 
physics  sequence  with  average 
between  C+  and  B 


One  calculus-based  physics 
course  with  C  or  better  grade 


I  No  pertinent  technical  courses 

•+ 
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II.  DIRECTOR  OF  ADMISSIONS  OFFICE 

A.   NATURE  OF  THE  PROBLEM 

> 
The   majority  of  undergraduate  transcripts  come  -from  the 

Naval  Academy   and  a   handful  of   NROTC  Universities.     The 

remainder  come  from  colleges  and  universities  all  around  the 

United  States.     Since   there   is   no   standard   transcript 

format,  it   is   necessary  that   each   one  be   reviewed,   and 

pertinent  information  summarized  to  assign  an  APC. 

Currently,  the  Director  of  Admissions  at  NPS  is 
calculating  QPRs  manually  and  assigning  APCs  based  on  hard 
copy  transcripts.  Considering  the  number  of  transcripts 
submitted  every  year,  this  process  is  not  only  time 
consuming,  but  costly  and  error  prone. 

The  Naval  Academy  has  agreed  to  provide  NPS  with 
approximately  one  thousand  undergraduate  transcripts 
annually  via  computer  tape.  If  this  one  input  were 
partially  automated,  it  could  result  in  a  twenty  to  thirty 
percent  reduction  in  workload  associated  with  the  assignment 
of  APCs. 

The  tape  consists  of  transcripts  sorted  by  student  ID  in 
ascending  order.  An  example  of  records  contained  on  the 
tape  is   shown   in   Table   IV.    The   individual  records  are 
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+ 

I  TABLE  IV 

I 

I  TRANSCRIPT  RECORD 

♦ 

I 

1841029  ABDUL  DAVID  BROS  512727258  SAS  H  HISPANIC 

I  SMI  1 1  V  081HE111  C  181HH103  C  181NS10UB  181PE101  C  181SC105  B  191 

! SI  100  A  181SN112  B  1B1NL102*B  2B1HH104  D  281HE112  B  281EN100«B  281 


JSI431  B  284SI412  B  284HH380  C  284NN412  B  284PE407  RD284PCR400C  284 

I 

+ 

separated  by   blank   lines.    Each   record   begins   with   an 
identification  line.   The  composition  of  the  line  is: 

1-  6  student  ID  number 

7  blank 
8-23  student  name 
24  blank 
25-33  social  security  number 

34  blank 
35-37  major 

38  blank 

39  sex  (M/F) 

40  blank 

41-48   race   or    -foreign    national 

After  the  identification  line,  the  courses  are  listed, 
six  per  line  in  blocks  of  11  characters  per  block.  Each  11 
character  block  consists  of s 
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1-  6  course  name 
7-  8  course  grade 
9-11  semester  taken 

Some  special  codes  are  used  throughout  the  file  to  aid 
in  transaction  processing.  The  grade  field  uses  "V"  and  "R" 
as  special  codes  to  indicate  courses  validated  or  repeated 
respectively.  Valid  entries  for  letter  grades  in  the  grade 
field  are  listed  in  Table  V. 

Additionally,  the  Naval  Academy  will  provide  a  computer 
tape  listing  of  course  names  and  credit  hours  associated. 
Course  names,  grades,  and  credit  hours  &re  required  to 
calculate  a  QPR  for  each  graduate.  An  example  of  the 
listing,  sorted  by  course  name  in  ascending  order  <A-Z,0-9), 
is  shown  in  Table  VI. 

Most  undergraduate  universities  calculate  a  Quality 
Point  Rating  in  the  same  manner.  Nevertheless,  two  problems 
arise  when  a  QPR  calculated  by  an  outside  source  is  used  by 
NPS  to  assign  an  APC.  The  most  straightforward  of  the  two 
is  the  conversion  from  the  three  point  to  the  four  point 
scale.  This  is  not  the  case  with  the  Naval  Academy,  hence 
the  solution  will  not  be  discussed  in  this  thesis.  On  the 
qualitative  side,  if  an  undergraduate  student  repeats  a 
course  and  receives  a  higher  grade,  only  the  higher  grade 
goes  into  the  calculation  of  a  QPR.  If  this  fact  were 
ignored   in   the  assignment   of  an  APC,  it  could  mean  that  a 
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+■ 

I 

: 


TABLE  V 
VALID  LETTER  GRADES 


NORMAL 


I 


VALIDATE  ** 


I   REPEATED  COURSE* 

+■ 


*   used    in    QPR   calculation*      ♦*   not    u 


in    QPR   calculations 


TABLE   VI 
COURSE   CREDIT  HOURS 


I 
SEA303,2 

:heih,3 

ISH201 ,4 


EE221 ,4 

HE442,3 
S0471,3 


EE494,2 
HH224,3 
SP440,3 


FE301,3 
HH362,3 
SP493,2 


FP314,3 
N810l*,3 
SR401 ,3 


*  indicates  courses  used   in  Military  QPR  calculation 

student  who  repeated  a  course  to  receive  a  passing  grade 
could  be  assigned  the  same  APC  as  a  student  who  easily 
completed  the  course  initially.  This  is  not  the  intention 
of  the  APC.  To  preclude  this  possibility,  all  undergraduate 
QPR's  are  recalculated  by  the  Director  of  Admissions  at  NPS. 
The  new  QPR  includes  all  grades  received  by  a  student,  and 
in  a  sense  becomes  a  common  denominator  for  academic 
evaluation. 
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B.   SYSTEM  REQUIREMENTS 

One  formal  report,  shown  in  Figure  2.1,  dictates  all 
system  requirements.  NPS  Form  5040/2  (revised  12/81), 
Academic  Record  Evaluation  is  a  transcript  summary  that 
facilitates  the  assignment  of  an  APC.  It  is  also  used  by 
the  Department  Chairman  to  aid  in  a  subjective  judgment  on 
whether  an  individual's  academic  background  will  support  a 
specific  masters  program.  The  queries  required  to  complete 
Form  5040/2  are  listed  below. 


1.  Count  the  number  of  courses   in  each   subject  area   by 
letter  grade. 

2.  Calculate  a  QPR  based  on  valid  letter  grade  and  course 
credit  hour  entries. 


Before  the  design  of  the  application  program  described 
above,  a  data  dictionary  was  implemented  to  aid  in  program 
development.  The  requirements  and  design  specifications  for 
the  data  dictionary  are  discussed  in  Chapter  4. 

The  decision  to  purchase  and  use  FOCUS  as  the 
administrative  DBMS  for  NPS  was  made  primarily  by  the 
Admissions  Office  programming  staff.  Their  choice  was 
heavily  influenced  by  programming  capabilities  and  a  modular 
pricing  policy.  Basic  FOCUS,  excluding  options  like 
financial  modeling  and  graphics,  can  be  purchased  for  less 
than  many  other  mainframe  systems.  Nevertheless,  it  is 
important  that  policy  and  decision  makers  be  involved  in  the 
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Figure    2.1      Academic   Record  Evaluation   Form 
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specification  of  system  capabilities.  A  problem  arises  when 
management  is  unfamiliar  with  common  DBMS  attributes.  It  is 
difficult  to  specify  requirements  without  being  familiar 
with  capabilities. 

Chapters  3  and  4  are  intended  to  provide  management  with 
a  background  and  understanding  of  the  capabilities  of 
current  DBMSs  and  data  dictionaries.  A  better  understanding 
should  allow  managers,  users,  and  programmers  to  take 
advantage  of  the  fourth  generation  environment  provided  by 
FOCUS. 


20 


III.  DATA  BASE  MANAGEMENT  SYSTEMS  AND  FOURTH 
GENERATION  LANGUAGES 

A.   COMPARISON  OF  DATA  BASE  MODELS 

>  . 

Be-fore  an  attempt  can  be  made  to  understand,  design, 
implement,  or  simply  use  a  DBMS,  a  data  model  is  needed.  In 
addition,  not  all  people  think  alike,  so  that  dif-ferent 
approaches  may  appeal  to  different  people.  Hence,  different 
data  models  may  be  needed. 

The  selection  of  a  DBMS  should  be  heavily  influenced  by 
the  data  models  and  resulting  logical  views  of  data 
provided.  FOCUS  is  primarily  based  on  the  hierarchical  data 
model.  It  should  be  determined  in  advance  that  data 
structures,  intended  applications,  and  users  are  compatible 
with  the  capabilities  and  limitations  of  the  data  model.  If 
they  are,  a  DBMS  that  implements  that  model  would  be  a  good 
choice. 

If  the  underlying  data  model  for  a  DBMS  is  not 
considered  before  implementation,  there  is  a  chance  that 
data  may  have  to  be  forced  into  incompatible  logical 
structures  to  conform  with  data  model  limitations.  The 
Administration  at  NPS  should  be  aware  of  the  strengths  and 
weaknesses  of  the  data  model  underlying  FOCUS  and  the 
available  alternatives. 


Over  the  past  ten  years,  no  -fewer  than  twenty  data 
models  have  been  proposed.  Each  has  its  own  concepts  and 
terminology.  There  are  three  major  models  currently 
implemented  by  commercial  systems.  The  -following  sections 
provide  an  overview  of  the  CODASYL,  Hierarchical,  and 
Relational  data  models  as  described  by  CRe-f.  1,23. 

1.   CODASYL 

The  words  schema  and  subschema  were  first 
highlighted  in  1969,  by  the  CODASYL  Data  Base  Task  Group 
(DBTG) ,  to  describe  different  views  of  data.  It  was  the 
concept  of  a  common  Data  Description  Language  (DDL)  that 
gave  rise  to  three  specific  views  of  data)  the  global 
conceptual  view  or  schema,  the  external  or  subschema  view, 
and  the  internal  view  or  physical  data  base  description. 

The  schema  is  the  complete,  logical  view  of  the 
database,  and  subschemas  are  subsets  of  schemas  as  viewed  by 
application  programmers.  Not  all  records  or  relationships 
of  a  schema  are  exposed  to  subschemas,  but  when  included  in 
a  subschema,  they  can  be  renamed  and  data-item  formats  can 
be  changed. 

To  aid  in  the  separation  of  physical  and  logical 
views  of  the  database,  the  schema  does  not  contain  the 
physical  description  of  the  database.  The  Data  Structure 
Definition  (DSD)  is  used  to  map  physical  storage 
requirements  and  to  specify  access  methods. 
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The  CODASYL  model  is  a  physical  database  model  that 
makes  use  of  data-items,  records,  and  a  relationship  called 
a  set.  A  set  consists  of  a  two-level  tree  of  records.  Each 
set  type  can  represent  a  relationship  between  two  or  more 
record  types.  Each  set  must  contain  one  occurrence  of  its 
owner  record  and  may  contain  any  number  of  member  records 
(one-to-many).  Figure  3.1  gives  an  example  of  a  CODASYL 
set. 

A  multilevel  hierarchical  file  or  simple  network  can 
be  regarded  as  being  composed  of  multiple  sets.  Each 
one-to-many  relationship  is  just  replaced  by  a  set.  An 
early  criticism  of  the  DBTG  proposed  DML  was  its  inability 
to  describe  complex  pi  ex  structures  also  known  as  networks. 
This  is  not  necessarily  a  serious  disadvantage  because  the 
complex  structures  can  be  decomposed  to  simple  networks  by 
defining  intersection  records.  What  does  suffer,  however, 
is  the  logical  view  of  the  data. 

The  CODASYL  Task  Group  also  addressed  important 
topics  such  as  logical  and  physical  independence  vs. 
response  time  and  data  integrity.  The  implementation  of 
areas  was  a  compromise  between  too  much  physical  control 
which  destroys  data  independence  and  too  little  physical 
control  which  sacrifices  response  time.  An  area  is  a  named 
subdivision  of  a  database.  They  are  intended  for  use  by  the 
DBA  to  enhance  system  efficiency  through  control  of  record 
placement. 
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Figure  3.1    Example  of  a  CODASYL  Set 

The  CODASYL  model  addressed  data  protection  by 
implementing  privacy  locks.  These  locks  are  imposed  at  any 
level  in  the  system  from  the  overall  schema  to  an  individual 
data  item.  Without  the  proper  key,  similar  to  a  password, 
the  update/modify  type  functions  can  be  inhibited. 

When  the  notion  of  a  standard  began  to  gain 
support,  so  did  the  controversy  over  what  the  standard 
should  be.  IBM's  Data  Language/I,  a  hierarchical  based 
language,  along  with  proposed  relational  systems  began  to 
challenge  CODASYL  for  the  title  of  industry  standard. 

2.   Hierarchical 


IBM  began  the   development  of  Data  Language/ I  (DL/I) 
in  the   1960 's  to   support  the   aerospace  industry.    It   is 
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still  the  basis  for  their  DBMS  called  Information  Management 
System  (IMS). 

In  DL/I,  a  field  is  the  smallest  unit  of  data.  A 
group  of  fields  is  known  as  a  segment  and  a  hierarchically 
structured  group  of  segments  constitutes  a  data  base  record. 
Each  relationship  between  records  is  one-to-many  with  all 
arcs  pointing  toward  the  leaves.  At  this  point,  the 
similarities  between  the  CODASYL  logical  set  and  DL/I 
hierarchical  structure  can  be  seen.  Figure  3.1  could  be 
relabeled  and  used  for  the  hierarchical  model.  As  a  result 
of  this  similar  tree  structure,  DL/I  must  transform  network 
relationships  into  hierarchical  form  in  much  the  same  way  as 
the  CODASYL  sets.  The  network  is  first  decomposed  into 
trees  with  duplication,  and  then  logical  pointers  &re  used 
to  remove  the  redundancy.  These  logical  child  pointers  make 
it  possible  to  represent  multiple  logical  structures  from 
any  number  of  physical  trees.  Figure  3.2  gives  an  example 
of  the  process. 

The  three  views  of  data  described  earlier,  are  not 
supported  by  DL/I  or  the  FOCUS  Data  Description  Language. 
The  only  distinction  made  is  between  logical  and  physical 
data  base  records.  A  logical  data  base  may  be  either  a 
subset  of  a  physical  data  base,  or  it  may  contain  parts  of 
two  or  more  physical  data  bases.  Segment  relationships  can 
be  present  in  the  logical  structure  that  do  not  exist  in  the 
physical  data  base. 
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Figure  3.2     Decomposition  of  a  Complex  Network 


Sensitivity  is  a  term  used  to  describe  the  ability 
of  application  programmers  to  maintain  separate  views  of  the 
same  data  base.  Application  programs  are  sensitive  only  to 
changes  made  in  the  physical  data  base  that  are  reflected  in 
their  logical  view.  In  some  cases,  the  physical  data  base 
may  be  modified  without  changing  application  programs.  In 
other  words,  the  logical  view  is  insensitive  to  unrelated 
changes  in   the   physical   data  base.     The   separation   of 


26 


logical  and  physical  views  is  an  important  step  toward   data 
independence. 

3.   Relational 


Dr.  E.  F.  Codd  -first  introduced  the  relational  model 
in  1970  CRef.  33.  As  early  as  1975,  this  model  was  being 
heralded  as  the  key  to  further  automation  in  database 
management  software.  Nevertheless,  it  was  not  until  the 
early  1980 's  that  a  commercially  viable  relational  DBMS  was 
available.  The  first  was  IBM's  SQL/DS,  followed  closely  by 
ORACLE  from  Relational  Software  Inc.  Both  systems  use 
Structured  Query  Language  (SQL)  for  query,  data 
manipulation,  and  data  definition. 

The  relational  model  is  unique  in  that  it  is  used 
only  for  the  logical  description  of  data.  A  relational 
database  can  be  physically  structured  many  different  ways. 
No  knowledge  of  the  underlying  data  structures  such  as 
linked  or  inverted  lists  is  required.  Physically  oriented 
models  can  inhibit  changes  to  data  that  may  be  needed  as  the 
database  grows,  because  the  changes  would  dictate  expensive 
application  program  modification. 

Two-dimensional  flat  files,  called  relations,  are 
used  to  represent  data  in  the  relational  model.  Columns  are 
called  attributes  and  rows  are  called  tuples.  Each 
attribute  must  have  a  unique  name  and  a  domain,  the  set  of 
values  that  the  attribute  can  have.    A  tuple  is  said  to   be 
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of  degree  n,  where   n  is  the  number   of  attributes.   No  two 

tuples  in  a   relation  can   be  identical  and   their  order  is 

insignificant.    The   generalized   form  of   a   relation  and 
several  occurrences  are   depicted  in  Figure  3.3. 
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Figure  3.3    Example  of   Relational  Flat  Files 

To  insure  a  flexible  and  consistent  logical 
representation,  Codd  designed  a  technique  called 
normalization.  First  normal  form  involves  the  elimination 
of  repeating  groups  by  specifying  that  each  attribute  must 
be  a  fact  about  the  key.  Second  normal  form  reduces 
redundancy  by  insuring  that  every  non-key  field  is  a  fact 
about  the  entire  key.  Third  normal  form  eliminates  deletion 
anomalies  by  specifying  that  a  non-key  field  cannot  be  a 
fact  about  any  other  non-key  field.   With  normalization   and 
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intersection  records,  any  representation  can  be  reduced  to 
two-dimensional  flat  files  with  some  redundancy. 

To  provide  a  subschema  that  is  logically  separate 
from  the  physical  database,  it  is  necessary  to  be  able  to 
extract  subsets  of  rows  and  columns  from  the  relations  that 
make  up  the  schema.  The  name  used  to  describe  this 
manipulation  of  relations  is  relational  algebra.  Using 
relational  algebra,  operators  are  defined  that  work  on 
relations.  The  practical  use  of  relational  algebra  is 
seldom  seen  because  of  its  procedural  structure,  but  the 
underlying  concepts  arc    important. 

The  advantage  of  a  nonprocedural  language  is  that 
the  user  specifies  what  is  required,  possibly  in 
English-like  terms,  and  the  system  can  optimise  how  to 
obtain  the  required  data.  Nonprocedural  language  interfaces 
have  taken  many  forms.  For  example,  SQL  is  a  nonprocedural 
transfer-oriented  language  that  is  capable  of  using 
relations  to  transfer  data  into  results. 

The  relational  model  is  the  most  widely  accepted  and 
adopted  in  commercial  applications  today.  The  individual 
reasons  vary  from  its  mathematical  basis  to  its  logical 
structure.  The  bottom  line  is  that  the  user,  whether  casual 
or  experienced  programmer,  can  understand  and  maintain  the 
resulting  logical  structure  much  more  easily  than  with  the 
previously  described  models. 
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In  a  small  database,  with  minor  applications,  there 
may  be  no  advantage  for  relational  over  network  or 
hierarchical.  However,  as  the  database  grows  and  data  and 
relationships  aro  added  and  changed,  a  properly  designed 
relational  system  often  is  much  simpler  and  less  expensive 
to  maintain.  Good  data  independence  and  normalized  form 
will  usually  allow  growth  and  change  in  the  database  without 
forcing  the  rewriting  of  application  programs.  Without 
these  characteristics,  the  cost  of  maintaining  an 
organization's  programs  and  data  can  quickly  rise  to  an 
unacceptable  level. 

B.   FOURTH  GENERATION  LANGUAGES 

NPS  is  still  new  to  the  data  base  environment  and 
already  a  programming  backlog  has  developed.  The  delay  for 
non-trivial  applications  can  exceed  six  months.  Possible 
solutions  include  hiring  more  programmers,  increasing 
existing  programmer  productivity,  and  involving  users  in 
application  proggram  development.  The  fourth  generation 
environment  provided  by  FOCUS  is  capable  of  increasing 
productivity  and  involving  users. 

The  evolution  of  computer  languages  has  occurred  in 
distinct  stages.  Machine  language,  patterns  of  ones  and 
zeros,  was  the  first  followed  by  second  generation  assembly 
language  which   used  symbols   and  mnemonics   to  replace   the 
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pattern*  of  zeros  and  ones.  Third  generation,  high-level 
procedural  languages  such  as  COBOL,  FORTRAN,  and  Pascal  were 
next  to  evolve.  With  each  stage  in  the  development  of 
human-computer  communication,  the  programmer  was  required  to 
know  less  about  the  physical  composition  of  data  structures. 

The  concept  of  data  independence,  where  the  programmer 
is  not  concerned  with  the  structure  of  data,  was  an  early 
goal  of  data  base  designers.  It  was  not  until  the  advent  of 
the  relational  data  base  that  this  goal  was  realized.  As  a 
result  of  its  data  independent  design,  the  relational  data 
base  facilitated  progression  to  the  next  stage  in  computer 
language  development,  the  fourth  generation  language  (4BL) . 
Richard  Cobb,  one  of  the  developers  of  the  first  4QL  said, 
"In  fact,  withoutO  structure-independent  DBMSs,  fourth 
generation  languages  would  never  have  come  into  existence." 
CRef.  4sp.  923 

There  are  two  main  differences  between  third  and  fourth 
generation  languages.  First,  the  number  of  programmed 
instructions  is  typically  less  when  4GLs  are  used.  But,  it 
is  the  nonprocedural  structure  of  4QLs  that  make  them 
unique.  A  user  tells  the  computer  what  he  wants  rather  than 
how  to  retrieve  it.  This  lends  itself  easily  to 
English-like  command  structures. 

Productivity  is  the  focus  of  most  comparisons  between 
third  and  fourth  generation  languages.  The  tendency  is  to 
perform  some  quantitative  analysis,  based  on  historical   and 
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projected  programmer  productivity,  to  support  the  transition 
to  -fourth  generation  operations.  Richard  Cobb,  developer  of 
Ramis  II,  computed  a  savings  of  approximately  *1, 000, 000 
with  a  4GL  versus  only  $23,000  with  a  36L.  Very  little 
effort  was  devoted  to  justifying  the  remaining  4QL  benefits. 
The  most  important  is  that  it  is  easily  used  by  both 
computer  specialists  and  end  users.  CRef.  4jpp.  91-973. 

Very  few  people  dispute  the  increase  in  individual 
programmer  productivity  with  4QLs,  although  some  have  been 
quick  to  point  out  other  weaknesses,  such  as  the  lack  of  an 
industry  standard.  The  development  of  computer  software  is 
moving  so  quickly  that  it  is  difficult,  at  times,  to 
determine  which  advance  is  a  step  and  which  is  a  landing. 
For  that  matter,  it  is  hard  to  tell  which  development  is  an 
advance.  Claims  that  organizational  productivity  bog  down 
because  of  the  impact  of  a  46L  product  on  the  existing 
environment  is  more  than  likely  a  result  of  the  environment 
and  not  the  46L.  Without  question,  systems  and 
organizations  will  have  to  change  to  take  advantage  of 
fourth  generation  application  development  capabilities.  It 
is  not  unusual  for  technology  to  dictate  change. 
Organizations  that  do  not  change,  but  rely  on  technology 
alone  to  increase  their  overall  productivity,  may  be 
disappointed  with  4GLs.  CRef.  5:pp.  99-1043 
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C.   COMMERCIAL  DATA  BASE  MANAGEMENT  SYSTEMS 

There  are  dozens  of   commercially   available   Data   Base 
Management  Systems.    Each   one  has   relative  strengths   anr 
weaknesses.   It  is   up  to  the   system  designer  to   determin 
requirements,  evaluate  the  available  systems,  assess   futur 
trends,  and  select  the  most  appropriate. 

Applications  and  systems  designers  may  suffer  from  a 
lack  of  flexibility  in  the  modeling  of  data  relationships 
due  to  constraints  imposed  by  a  particular  DBMS.  They  are 
forced  to  compromise  in  their  selection  of  data  models.  In 
some  cases,  applications  are  so  diverse  that  multiple  data 
models  are  employed,  necessitating  the  use  of  more  than  one 
DBMS. 

According  to  Has  Patel ,  Manager  of  Product  Planning  for 
MSP  Inc. ,  the  solution  is  to  plan  an  environment  in  such  a 
way  that  the  DBMS  is  separated  from  the  application  system. 
He  asserts  that  the  emphasis  should  be  placed  on  Logical 
Data  Structure  Designs  <LDSD)  which  are  independent  of 
physical  DBMS  implementations.  This  could  be  accomplished 
with  a  data  dictionary  as  a  tool  for  the  management  and 
control  of  a  corporate  data  resource.  CRef.  6: pp.  86-91] 

A  DBMS  should  perform  the  following  functions! 


*  Define  and  store   the  data  base   structure  using  a   data 
definition  language. 

*  Load  data  into  the  data  base  from  terminals  or   external 
data  files. 
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*  Provide  a  wide  variety  of  access  methods  such  as 
sequential  and  keyed.  Promote  logical /physical 
independence  by  automatically  updating  the  physical  data 
base  when  changes  are  made  to  the  logical  structure. 

*  Provide  multiple  views  of  data  depending  on  class  of 
user . 

*  Provide  security  features  to  control  access  to  data 

*  Enable  control  over  concurrent  operations  to  allow 
read/write  access  to  multiple  users. 

*  Facilitate  backup  and  recovery  with  rollback  and 
rollforward  utilities. 

*  Provide  data  manipulation  capabilities  via  query 
language. 

*  Provide  report  generation  capabilities. 


To  aid  in  the  selection  of  an  appropriate  DBMS,  short 
summaries  with  applicable  comments  on  each  of  twenty-five 
commercial  systems  are  provided  in  the  next  sections. 
Table  VIII  lists  vendor  information  and  data  model  basis  for 
a  number  of  popular  DBMSs.  The  "self-contained"  designation 
in  Table  VIII  signifies  that  the  DBMS  is  based  on  its  own 
internal  model.  These  self-contained  models  usually 
consist  of  some  combination  of  the  three  major  data  models 
discussed  earlier. 

1.   Accent  R 

ACCENT  R  is  a   relational   DBMS  marketed  by  National 

Information  Systems,  Inc.   It  is  designed  to  run  on   Digital 

Equipment  Corporation  DEC  system-10/20  under  the  TOPS-10/20 
or  VMS  operating  system. 

34 


+ ♦ 

TABLE  VII 

DATA  BASE  MANA6ENENT  SYSTEMS 


DBMS  NAME 
Accent  R 

AOABAS 
Condor 


Data  Management 
IV 

Datacom/DB 

Dbase  II 


DBM8-990 
DBMS-Prime 
DMS  1100 
DMS-170 
DRS 

Encompass 

Express 

Focus,  PC/Focus 

IDIS 


VENDOR 

National  Information  System 
2037Q  Town  Ctr.  Ln. ,  Suite  130 
Curpertino,  CA.  95014 

Software  A6 

Condor  Computer  Corporation 
2051  South  State 
Ann  Arbor,  MI.  41804 


Applied  Data  Research,  Inc. 

Ashton-Tate 

10150  Jefferson  Blvd. 

Culver  City,  CA.  90230 

Texas  Instruments 

Priee  Computer  Incorporated 

Sperry  Computer  Systems 

Control  Data  Corporation 

Advanced  Data  Management 
15-17  Main  St. 
Kingston,  NY.  08528 

Tandom  Computers,  Inc. 

Management  Decision  Systems 

Information  Builders,  Inc. 

1250  Broadway 

New  York,  NY.  10001 

Intel  Corporation 
3065  Bowers  Avenue 
Santa  Clara,  CA.  95051 


MODEL 
Relational 

Self-Contained 
Relational 


Honeywell  Information  Systems    C0DASYL 


Relational 
Relational 

Self-Contained 

Self-Contained 

CODASYL 

C0DASYL 

Self-Contained 

Self-Contained 

Relational 

Self-Contained 

Relational 
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TABLE  VII 

DATA  BASE  MANAGEMENT  SYSTEMS  (CONT.) 


DBMS  NAME 
IDMS/R 

Iaage 

IMS 
Info 

Ingres 

Inquire 

MDBS  I 

MDBS  III 

Model  204 

Noaad2 

Oracle 


VENDOR 

Cullinet  Software,  Inc. 

400  Blue  Hill  Dr. 

Westwood,  Massachusetts  02090 

Hewlett  Packard 

19447  Pruaeridge  Avenue 

Cupertino,  CA.  95014 

IBM  Corporation 

Henco  Software  Inc. 
100  Fifth  Ave. 
Walthaa,  MA.  02154 

Relational  Technology,  Inc. 
2855  Telegraph  Ave. 
Berkeley,  CA.  94705 

Infodata  Systeas  Inc. 

5205  Leesburg  Pike 

Falls  Church,  Virginia  22041 

ISE-USA 

85  Nest  Algonquin  Road 

Arlington  Heights,  IL.  60005 

ISE-USA 

85  West  Algonquin  Road 

Arlington  Heights,  II.  60005 

Computer  Corporation  Of  Aaerica 

4  Caabridge  Center 

Caabridge,  Massachusetts  02142 

DttB  Coaputer  Services 
187  Danbury  Road 
Wilton,  CT.  06897 

Oracle  Corporation 
3000  Sand  Hill  Road 
Menlo  Park,  CA.  94025 


MODEL 
Relational 

Network 

Hierarchical 
Relational 

Relational 

Self-Contained 

C0DASYL 

Self-Contained 

Self-Contained 

Relational 


Relational 


+ _ + 
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TABLE  VII 
DATA  BASE  MANAGEMENT  SYSTEMS  (CONT.) 


DBMS  NAME 
Raais  II 

Rapport 

Relate/3000 

Rubix 

Seed  DBMS 

SQL/DS 
Systea  1022 

Systea  2000 


The  Knowledge 
Manager 


VENDOR 

Matheaatica  Products  6roup 

P.O.  'Box  2392 

Princeton,  New  Jersey  08540 

Logica,  Inc. 

3  Eabarcadero  Center 

San  Francisco,  CA.  94111 

Coaputer  Resources,  Inc. 
5333  Betsey  Ross  Dr. 
Santa  Clara,  CA.  95054 

Infosysteas  Technology 
6301  Ivy  Lane 
6reenbelt,  MD.  20770 

Seed  Software/United  Telecoa 
2300  Walnut  St.,  Suite  734 
Philidelphia,  PA.  19103 

IBM  Corporation 

Software  House 
Caabridge,  MA.  02138 

Intel  Systeas  Corporation 
3065  Bowers  Avenue 
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The  storage  structure  consists  of  either  -fixed  or 
variable  length  records.  All  indexes  for  a  given  data  file 
are  combined  into  one  independent  index  file.  Records  may 
be  accessed  through  keyed  or  unkeyed  fields  and  RAM  indexes 
provide  fast  keyed  retrieval. 

Data  entry  is  controlled  by  commands  that  allow 
input  to  chosen  fields,  prompting,  duplication  of  values, 
pre-testing  for  errors,  and  validation  based  on  a  data  file. 
Field  names  are  up  to  forty  characters  long  and  are  of  types 
integer,  real,  double  precision,  character,  alpha,  date, 
bit,  and  user  defined. 

Accent  R  provides  a  non-procedural  natural  query 
language,  a  high-level  structured  programming  language,  and 
host  language  interfaces  for  FORTRAN,  COBOL,  and  BASIC. 

The  Data  Base  Library  is  an  actively  maintained 
dictionary.  It  provides  information  about  how  programs  and 
data  are  structured,  processed,  and  related.  It  works  with 
a  utility  named  SOMOD  to  recompile  all  necessary  programs 
when  a  change  is  made. 

2.   Adabas 

Adabas  is  comprised  of  the  Associator  (inverted 
lists,  coupled  lists  and  system  file),  Data  Storage,  and 
Work  Storage  (temp  space).  Numerous  utilities  are  used  to 
load  the  data  base,  add  new  fields,  add  new  paths,  define 
new  relationships,   and   sequence  files   without   resorting. 
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The  data  base  -files  are  described  to  the  data  dictionary 
which  contains  information  about  the  characteristics  of  data 
items,  such  as  their  relationship  to  other  items  and  where 
they  are  used. 

A  comprehensive  backup  and  recovery  facility  logs 
all  changes  to  the  data  base  and  writes  coordinated 
checkpoints.  Partially  completed  transactions  are  removed 
and  the  data  base  can  be  restored  to  any  checkpoint  if  a 
failure  occurs. 

Host  language  calls  to  ADABAS  are  embedded  in  COBOL, 
FORTRAN,  PL  1,  and  Assembler.  ADASCRIPT+,  ADACOM,  and 
NATURAL  data  manipulation  languages  are  provided. 

3.   Datacom 

Datacom  is  designed  for  use  with  IBM  mainframe 
equipment  and  operating  systems.  System  utilities  provide 
high-speed  loading,  unloading,  and  recovery.  DATACOM  offers 
complete  transaction  backout,  rol 1 -forward ,  and 
roll-backward  restart  and  recovery  capabilities.  Data  base 
files  may  be  recovered  or  restored  from  any  point  in  time. 

Record  locking  is  automatic  at  the  logical  record 
level.  A  program  may  have  many  records  locked  concurrently. 
Data  contention  situations  are  reported  to  the  user  in  the 
data  base  statistics.  Deadlock  is  detected  and  resolved  by 
the  system. 
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A  DATADICTIONARY  -facility  describe*  the 
characteristic*  of  data  items  within  the  data  base.  Their 
relation  to  other  items,  applications,  and  involvement  in 
the  entire  system  are  also  included.  This  is  an  active 
dictionary  -facility  that  contains  the  control  data  used  to 
drive  Datacom. 

Data  manipulation  may  be  accomplished  using 
application  programs  written  in  either  COBOL,  PL  1,  ALC, 
FORTRAN,  or  RP6.  A  high  level  language  -facility  (ADR/DL)  is 
available  to  de-fine  and  manipulate  data  using  English-like 
statements.  IDEAL  is  a  self-contained  relational 
4th-generation  language.  DATAQUERY  is  a  self-contained 
relational  query  language. 

4.   Dbase  1 1 

A  microcomputer  based  relational  DBMS,  dBase  II 
requires  CP/M  2.2  or  later  for  8  bit  systems  or  PC-DOS, 
MS-DOS,  or  CPM  86  for  16  bit  systems.  Files  are  stored  as 
fixed  length  ASCII  data.  Access  is  sequential  or  random 
using  inverted  B-tree  indexes. 

The  query  language  allows  memory  variable  storage  to 
be  saved  to  disk,  and  restored  later.  Access,  security,  and 
validation  can  also  be  accomplished  through  use  of  the  query 
language.  The  on-line  environment  allows  the  user  to  access 
any  of  several  records,  edit  them  or  browse  through  the  data 
base.   No  active  dictionary  support  is  currently  available. 
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5 •   DBMS  -  Prime 

DBMS  -  Prime  is  a  CODASYL  based  system.  It  supports 
CODASYL  DDL,  COBOL,  FORTRAN,  and  CODASYL  DML  commands. 
Sub-schema  compilers  for  FORTRAN  and  COBOL  generate  object 
sub-schema  files  and, a  DML  preprocessor  converts  CODASYL  DML 
statements  to  host  language  calls. 

A  schema  editor  is  available  to  support  revising  the 
schema  in  an  interactive  mode.  The  stored  data  base  is 
automatically  revised  to  correctly  reflect  any  changes  to 
the  schema.  Whenever  a  sub-schema  is  recompiled,  the  system 
insures  that  all  associated  programs  are  recompiled. 

Data    integrity   is   preserved   through   extensive 

failure  protection  procedures.  An  automatic  rollback  to  the 
end  of  the  last  completed  transaction  on  program  failure, 
rollback  utility  on  system  failure,  and  rollforward  utility 
for  system  or  media  failure  are  just  a  few. 

6.   Data  Manager  IV 

Honeywell  Information  Systems  <HIS)  markets  a 
comprehensive  on-line  CODASYL  based  DBMS  named  DATA  MANAGER 
IV  (DMIV).  As  with  most  CODASYL  implementations,  data  base 
integrity  is  provided  by  before  and  after  images,  rollback 
and  rollforward  functions,  and  checkpointing.  Every 
sub-schema  must  be  validated  against  the  schema  and  a  user 
generated  DML  permitted/prohibited  list. 
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Data  base  initialization  and  restructuring  are 
accomplished  through  utilities.  Initial  and  subsequent  data 
loading  are  via  COBOL  or  FORTRAN  user  programs  (no 
preprocessor  required).  Any  record  type  may  be  defined  as 
owner  or  member  in  any  number  of  sets.  This  provides 
hierarchical,  tree,  and  network  capabilities.  If  desired, 
the  entire  data  base  may  be  viewed  as  a  relational, 
table-oriented  data  base.  In  support  of  this,  HIS  provides 
IQ,  EQ,  and  RQ ,  three  new  relational  languages. 

HIS  also  provides  a  Data  Dictionary/Directory  System 
(DD/DS)  that  supports  up  to  eighteen  different  entity  types 
and  their  relationships.  It  can  produce  fifty-eight  unique 
reports. 

7.   DM3  1100 

Marketed  by  Sperry  Computer  Systems,  DMS  1100  is  a 
CODASYL  DBMS  for  use  with  all  Sperry  series  1100  computers. 
Item  descriptions  are  based  on  COBOL-oriented  CODASYL 
specifications  including  level  number,  name,  picture,  usage, 
occurs,  and  occurs  depending  on  clauses.  Item  definitions 
can  include  a  CHECK  clause  for  data  validation. 

Data  base  creation  and  input  are  accomplished  via 
user  application  programs  or  with  a  special  "load"  schema. 
Modifications  require  some  reloading  and  recompi lation  of 
programs.   The   Data  Dictionary  System   <DDS) ,  a   dependent, 
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active  data  dictionary,  can  aid  data  base  revision  with 
impact  reports. 

Application  programming  can  inter-face  with  COBOL 
FORTRAN  and  PL/1.  DMS  1100  provides  two  other  data 
manipulation  languages.  QLP  1100  is  a  command-oriented  data 
manipulation  language  and  RPS  1100  is  a  form-oriented  screen 
image  report  language.  Both  languages  supplied  are  designed 
•for  use  by  the  end  user. 

Automatic  and  utility  based  roll  back  and  recovery 
facilities  are  provided.  Roll  back  can  affect  only 
individual  users  or  programs,  or  all  active  programs  at  the 
time  of  system  failure.  Selective  file  recovery  is  possible 
and  an  entire  data  base  may  be  recovered  to  a 
pre-established  recovery  point. 

8.   DRS 

DRS  is  a  powerful  self-contained,  rel ational-1 i ke 
DBMS  produced  by  Advanced  Data  Management.  It  is  designed 
to  operate  with  most  DEC  VAX  and  PDP  systems,  as  well  as  IBM 
mainframes.  A  multi -processor  version  of  DRS  for  VAX  allows 
a  data  base  and  its  users  to  be  spread  across  several 
machines. 

There  are  two  types  of  files  supporting  the  physical 
structure  of  a  DRS  data  base.  The  first  is  the  Record 
Address  file  that  tracks  record  location  by  file  and  page. 
A  version  of  this  bit  map  marks  the  locations  of   qualifying 
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records  after  a  retrieval  so  they  do  not  have  to  be  copied 
to  temporary  storage.  Secondly,  indexes  are  maintained 
through  inverted  files  in  a  B-tree  format.  Any  field  or 
combination  of  fields  can  be  indexed.  Even  partial  field 
indexing,  where  a  single  word  or  phrase  in  a  field  is 
indexed,  is  available.  The  storage  area  for  records  can 
consist  of  up  to  1000  logically  concatenated  physical  disk 
files.  Each  file  is  divided  into  fixed  length  units  called 
pages.  The  structure  and  attributes  of  each  data  base  are 
stored  in  a  central  dictionary  data  base.  They  are  accessed 
via  an  interactive  display-oriented  utility  called  Data  Base 
Bui lder . 

Concurrent  read/write  access  to  a  data  base  is 
available  for  up  to  64  users.  Concurrent  read  only  access 
is  unlimited.  Automatic  locking  occurs  at  the  record  level 
while  a  record  instance  is  actually  undergoing  update. 

DRS  is  an  English-like,  self-contained  language  for 
query  and  update.  XBS  and  SIP  are  the  host-language 
interface  and  forms-oriented  query  and  update  language 
respectively.  Link  modules  and  XBS  programs  may  be  written 
in  any  standard  compiled  language. 

9.   Encompass 

Tandem  Computers,  Inc.  have  developed  a 
self-contained  DBMS  for  use  on  all  Tandem  NonStop  systems. 
It  will  allow  data  and  applications  to  be  distributed  across 
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a  255-node  network.  A  unique  relational  data  base  access 
method  named  EN8CRIBE  ensures  that  no  single  failure  will 
result  in  corruption  or  loss  of  data.  In  fact,  failed 
components  may  be  serviced  while  the  rest  of  the  system 
remains  in  operation.  The  Transaction  Monitoring  Facility 
can,  if  a  failure  occurs,  back  out  an  entire  transaction 
across  all  nodes  of  a  distributed  system.  Data  bases  are 
reconstructed  by  rolling-forward  from  on-line  dumps  and 
audit  trails. 

The  data  dictionary  plays  an  important  role  for 
ENCOMPASS.  The  on-line  dictionary,  built  with  the  Data 
Definition  Language  Processor,  provides  a  view  of  relational 
data  bases.  Under  the  purview  of  the  dictionary,  these  data 
bases  can  be  queried  by  ENFORM,  the  query/report  writer 
language,  or  validated/updated  by  PATHWAY,  the  transaction 
processing  system.  ENFORM,  with  the  data  dictionary, 
supports  field  level  security  by  allowing  multiple 
dictionaries  to  describe  the  same  data  base.  Only  those 
fields  explicitly  mentioned  in  the  dictionary  are  accessible 
to  the  user  of  that  dictionary. 

10.  Express 

Management  Decision  Systems,  Inc.  claim  that 
EXPRESS,  their  relational  DBMS,  offers  the  widest  range  of 
decision  support  system  tools  using  a  single  command  syntax. 
These  tools   include  data   management,  reporting,   graphics, 
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simulation,  ad  hoc  query,  statistics,  and  modelling. 
EXPRESS  is  available  for  IBM  mainframe  and  Prime  400  or 
larger  computers.  A  large  library  of  statistical,  plotting, 
financial,  and  market  modeling  routines  along  with  the 
ability  to  easily  use  and  create  new  EXPRESS  commands  makes 
this  DBMS  user  friendly. 

The  data  base  is  a  collection  of  multidimensional 
variables.  The  user  may  work  with  up  to  256  dimensions  at 
one  time  and  may  establish  hierarchical  relationships 
between  any  dimensions. 

The  system  is  designed  primarily  for  interactive 
processing  although  batch  may  be  accomplished  by  storing 
commands  in  a  file.  Concurrent  read/write  access  is  not 
provided  by  the  system.  Read  only  access  by  multiple  users 
is  possible. 

1 1 .  Focus 

Focus  and  PC  Focus  are  manufactured  and  sold  by 
Information  Builders,  Inc.  They  are  designed  to  operate  on 
the  IBM  370  and  IBM  PC  (minimum  of  5MB  external  storage) 
respectively.  As  with  any  hierarchical  system,  many-to-many 
relational-like  structures  can  be  designed  but  present 
complicated  logical  views.  Focus  is  the  Administrative  DBMS 
at  NPS.   More  information  can  be  found  in  Chapters  4  and  5. 
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12.  Intel's  Database  Information  System  (IDIS) 

IDIS  is  a  standalone,  relational,  micro-system 
package  with  mainframe  access  capability  to  SYSTEM  2000. 
Mainframe  data  download  statistics  Are  provided  before 
actual  local  database,  load  to  prevent  out  of  memory  errors. 

Intel  provides  spreadsheet  and  graphics  integration, 
a  word  processing  interface,  and  several  interactive  menu 
driven  utilities.  A  data  dictionary  is  integral  with  IDIS 
and  a  local  dictionary  driven  data  download  from  mainframe 
is  included. 

This  is  one  of  the  DBMSs  that  makes  full  use  of  the 
UNIX  (or  XENIX  by  Microsoft)  operating  system.  IDIS 
provides  access  to  XENIX  file  structure  and  word  processing 
interface  for  easy  cataloging  as  well  as  the  XENIX  mail  and 
calendar  facilities. 

1 3 .  Integrated  Database  Management  System  <IDMS) 

IDMS  was  developed  by  Cullinet  Software  for  IBM 
360/370  series  computers.  A  dependent  data  dictionary 
called  Integrated  Data  Dictionary  is  also  available.  In 
combination,  these  two  constitute  a  powerful  C0DASYL 
implementation  of  a  DBMS.  A  relational  version  called 
IDMS/R  is  also  available. 

Data  description  uses  standard  C0DASYL  set 
relationships.   Data   manipulation  is   through  COBOL,   PL/1, 
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Assembler,  CALL,  or  FORTRAN.  An  option  is  available  that 
allows  a  multitasking  environment  and  ensures  that  more  than 
one  task  does  not  update  the  same  record  at  the  same  time. 

Applications  programming  is  through  call  statements 
generated  by  a  preprocessor.  Operators  and  functions  are 
limited  to  those  provided  by  the  host  language. 

14.  IMS 

Up  to  31  on-line  application  programs  may  access  an 
on-line  data  base  using  IBM  Corporation's  DBMS  named  IMS. 
Since  IMS  is  designed  for  IBM  mainframe  computers,  a  heavy 
emphasis  is  placed  on  access  efficiency,  security,  and 
control . 

Special  storage  techniques  are  used  to  minimize 
storage  requirements.  Free  space  can  be  reserved  in  advance 
to  allow  later  insertion  of  segments  near  their  parents  or 
insertion  of  new  root  segments.  Deleted  segment  space  can 
be  reused  for  new  data. 

IMS  provides  automatic  logging  of  all  changes  to  any 
data  base.  It  also  contains  recovery  utilities  for 
restoration  without  re-execution  of  application  programs. 

Program  Isolation  Trace,  a  utility  provided  by  IMS, 
shows  locking  and  deadlocking  conditions.  IMPARS,  a 
productivity  aid,  can  be  used  to  report  internal  response 
time   and   resource   utilization.     Dictionary   support   is 
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available  through   DB/DC   Data  Dictionary   Systems,   an   IMS 
dependent  data  dictionary  package  also  by  IBM. 

IMS  is  best  suited  for  real  world  data  applications 
which  exhibit  hierarchical  relationships. 

15.  Info         | 

Info  is  a  mini-computer  oriented,  relational  data 
management  system  produced  by  Henco  Software  Inc.  An 
integrated  data  dictionary  is  used  to  describe  logical 
records  to  a  file  and  is  stored  separately  from  the  data 
base.  By  creating  a  dictionary  file,  INFO  can  access  files 
already  existing  in  the  system.  Minimum  input  validation  is 
also  accomplished  by  the  data  dictionary. 

A  combination  of  a  user-friendly  language  called 
INFO  and  multiple  add-on  products,  make  INFO  appealing  to 
end  users.  INFO-Veisagraph  provides  full  business  graphics 
linked  to  data  files.  INFO-Text  joins  unstructured  data 
created  by  a  word  processor  to  INFO  data  files.  Also,  a 
financial  planning  and  modeling  system,  called  MODEL,  can 
automatically  pull  data  from  INFO  to  the  correct  model  row 
and  column. 

The  programming  staff  is  assisted  by  INFO-Call  which 
links  INFO  to  programs  written  in  a  compiled  language. 
INFO-Flow  automatically  documents  INFO  application  programs. 
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16.  Ingres 

A  DEC  mini  or  68000  based  micro  computer  with  five 
megabytes  of  secondary  storage  is  all  that  is  required  to 
run  INGRES,  a  relational  DBMS  by  Relational  Technology,  Inc. 

As  with  most <  relational  systems,  relationships  are 
established  through  tables.  QUEL,  a  non-procedural  query 
language,  can  be  used  interactively  or  embedded  in  BASIC,  C, 
COBOL,  FORTRAN,  or  PASCAL. 

Query-By-Forms,  Report-By-Forms,  and  Braph-By-Forms 
are  all  designed  to  free  the  user  from  systems  programming. 
Ad  hoc  queries,  reports,  and  graphics  can  be  obtained 
without  formal  programming.  Application-By-Forms  is  an 
integrated  application  development  system  used  to  accelerate 
the  programming  process. 

17.  Inquire 

A  modified  relational  structure  was  used  by  Infodata 
Systems  Inc.  to  design  INQUIRE  for  IBM  mainframe  computers. 
In  this  modified  structure,  each  record  entity  can  be  made 
up  of  a  flat,  single  entry  "owner"  element  with  repeating 
"member"  groups.  Similarity  between  this  modified 
relational  structure  and  the  hierarchical  model  is  useful  in 
that  hierarchical  structures  are  a  byproduct  of  this 
approach.    It   could  just   as   easily  have   been   called   a 
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modified  hierarchical  structure   with  network   relationships 
as  a  byproduct. 

A  single  command  language  -for  query,  report,  and 
data  maintenance  provides  system  continuity.  Custom  macros 
can  be  used  to  create  additional  commands. 

18.  The  Knowledge  Manager  (Knowledgeman) 

Micro  Data  Base  Systems,  Inc.  developed 
KNOWLEDGEMAN,  a  relational  DBMS,  for  use  on  the  IBM  PC. 

KNOWLEDGEMAN  structured  programming  language  can  be 
used  to  invoke  all  data  management  commands.  It  supports 
thirty  built-in  functions  as  well  as  if-then-else,  do-while, 
and  case  logic.  In  addition,  it  is  capable  of  output 
conversion  to  ASCII,  BASIC,  or  DIF  format. 

During  data  base  creation,  the  user  is  prompted  for 
values  via  a  standard  or  customized  CRT  form.  At  that  time, 
multiple  indexes  can  be  defined  for  each  relation.  Index 
keys  can  be  made  up  of  multiple  fields  or  expressions 
involving  multiple  fields.  KNOWLEDGEMAN  allows  virtual 
fields  which  require  no  storage  space,  as  they  only  exist 
during  execution.  Virtual  fields  may  also  be  defined  by 
expressions  involving  other  fields. 

A  limited  distributed  capability  is  provided  by  a 
facility  for  downloading  MDBS  III  DBMS  data  files  into 
KNOWLEDGEMAN  for  local  use. 
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19-  The  Micro  Data  Base  System  III  <MDB3  III) 

Post-relational  is  how  ISE-USA,  the  creator  of  MDBS 
III,  classifies  their  DBMS.  MDBS  III  supports  hierarchical, 
relational,  and  CODASYL  views  as  subsets  of  its 
capabilities.  One-to-one,  one-to-many,  many-to-many, 
recursive  one-to-many,  recursive  many-to-many,  and  various 
other  relationships  Are  directly  represented  by  name  in 
MDBS  III.  This  allows  a  relational  join  to  be  accomplished 
by  simply  specifying  relationship  names.  Also,  virtual 
views  are  supported  that  lack  the  access  and  storage 
inefficiencies  of  actual  tables. 

MDBS  III  provides  a  query  language  that  is 
comparable  to  SQL  (by  IBM)  and  an  interactive  data 
manipulation  language  that  can  be  embedded  in  over  twenty 
host  languages.  A  data  dictionary  is  integral  with  the 
system  and  can  be  accessed  through  the  query  or  data 
manipulation  language. 

In  addition,  MDBS  III  provides  several  end  user 
oriented  applications.  Screen  Master  is  an  I/O  management 
system.  The  Report  Definition  Language  (RDL)  along  with  the 
RDL  Analyzer  allow  a  non-programmer  to  specify  the  format  of 
a  desired  report.  RDL  can  also  automatically  generate  C 
source  code  for  the  requested  report. 
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20.  Nomad2 

Nomad2,  a  relational  DBMS  by  D&B  Computer  Services, 
is  designed  for  on-line  (IBM  main-Frame)  interactive  problem 
solving  by  end  users.  It  employs  an  English-like 
non-procedural  command  language  for  reporting  and  updating. 
Relational  and  multipath  hierarchical  data  base  structures 
are   also  supported. 

The  data  management  facility  allows  for  easy 
creation  and  maintenance  of  data  base  files.  Data 
validation  spans  the  range  from  discreet  values  and  sets  to 
complex  logic  that  may  be  made  a  part  of  the  data  base 
description.  The  SLIST  facility  provides  integrated  data 
dictionary  functions  such  as  access  to  names  and 
characteristics  of  data  items. 

The  schema  may  be  modified  or  reorganized  without 
dumping  and  reloading  data.  System  checks  ensure  that  no 
changes  are  made  until  their  validity  is  verified. 
Hierarchical  segments  may  also  be  added,  provided  they  do 
not  interrupt  an  existing  path. 

Nomad2  is  designed  as  a  shared  data  base  facility 
which  directly  supports  multiple  concurrent  write  access. 
Conflicting  updates  are  handled  automatically  and  deadlock 
situations  are    prevented  by  the  system. 
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Numerous  other  aids  such  as  an  automatic  procedure 
generator  and  an  interactive  debugging  routine  make  N0MAD2  a 
stand-alone  applications  development  tool. 

2 1 .  Oracle 

Oracle  was  one  o-f  the  -first  relational  mainframe 
packages  to  be  commercially  available  on  a  micro  computer. 
It  is  highly  portable  and  flexible  enough  to  support  ad  hoc 
queries  as  well  as  serious  application  programming. 

Oracle  Corporation  implemented  SQL  Plus,  an  extended 
version  of  IBM's  SQL/DS,  as  the  standard  interface  to 
ORACLE.  SQL  serves  as  a  query,  data  manipulation,  and  data 
definition  language  and  provides  full  dictionary  support. 
Host  language  precompilers  are  available  for  most  languages 
with  embedded  call  statements. 

Normalized,  two-dimensional  tables  are  used  to 
represent  all  data.  Access  methods  are  determined 
dynamically  by  available  inverted  keys,  physical  sequences, 
uniqueness  characteristics,  and  data  distribution. 

22.  Ramis  II 


Mathematica  Products  Group  markets  Ramis  1 1  as  the 
first  fifth  generation  software  product  for  use  on  IBM 
mainframe  and  compatible  hardware.  Hierarchical,  network, 
and  relational  file  structures  are  supported.  The  natural 
language  processor,   Ramis   II   English,   is   based   on   the 
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principles  of  artificial  intelligence  and  can  understand  and 
answer  queries  made  in  everyday  English. 

Reporter,  a  non-procedural  language,  is  used  to 
produce  tabular  reports.  Application  programming  can  be 
done  in  COBOL,  PL/1,  Assembler,  and  FORTRAN  through  calls  to 
the  data  manager. 

Failure  protection  is  provided  by  transaction  log 
files.  Access  security  and  control  are  accomplished  through 
passwords  and  encryption  at  all  levels  from  data  base  to 
individual  fields. 

A  number  of  special  utilities  are  also  provided  that 
make  Ramis  II  a  portable  and  complete  application 
development  environment.  REF  extends  access  to  non-Ramis 
files  such  as  Adabas,  DL/1,  IDMS,  IMS,  and  Total.  RAMASTER 
is  a  file  dictionary  that  contains  information  about  each 
field.  FSM  allows  user-defined  screen  formats  of  up  to  99 
frames  to  be  created.  RAMLink  provides  a  PC-to-mainf rame 
link. 

23.  Structured  Query  Language  /  Data  System  (SQL/PS) 

SQL/DS,  by  IBM,  is  setting  the  standard  in  industry 
for  a  relational  DBMS.  It  is  designed  for  use  on  IBM  System 
370  computers. 

SQL,  the  system  language,  can  be  embedded  in  COBOL, 
FORTRAN,  PL/1,  Assembler,  or  used  solely  in  an  interactive 
mode.   It  is  the  most  imitated  aspect  of  SQL/DS.   Most  other 
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system  functions  such  as  data  base  creation,  failure 
protection,  and  input  validation  provide  adequate 
capabilities  but  are  often  overshadowed  by  more  recent  DBMS 
developments. 

24.  System  2000  > 

IBM,  UNIVAC,  CDC,  and  CYBER  computers  are  all 
compatible  with  System  2000,  a  DBMS  produced  by  Intel 
Systems  Corporation. 

System  2000  supports  linear,  hierarchical,  network, 
and  relational  logical  structures.  Each  data  base  is 
composed  of  up  to  six  direct  access  tables  such  as  the 
integrated  data  dictionary,  indexes,  and  raw  data.  Initial 
data  base  loading  may  be  accomplished  one  at  a  time  or  via 
PLEX  (Programming  Language  Extension),  a  high  speed  load 
utility  . 

The  Integrated  Data  Dictionary  plays  an  important 
role  in  System  2000.  For  each  physical  data  base,  the 
dictionary  parameters  include  archives,  update  journals,  and 
bef ore-image  logs.  All  internal  restructuring  is  done 
automatically  by  the  Basic  Data  Dictionary  Language.  It 
also  provides  password  based  security  down  to  the  individual 
item  level.  Input  data  can  be  validated  for  size,  type,  and 
picture  specified  by  the  schema  definition.  Additionally, 
report  requests  may  be  made  from  catalogued  procedures 
stored  within  the  Basic  Data  Dictionary. 
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System  2000  offers  several,  powerful,  user — oriented 
interfaces.  Quest  is  a  free-form  query  and  update  language. 
Genius  is  a  conversational  report  writer  and  syntax 
generator.  QUEX  (Query/Update  by  Example)  is  a  menu  driven 
formatted  screen  query  and  update  system.  Lastly,  System 
2000  On  Line  Operations  (SOLO)  offers  menu  driven  access  to 
all  previously  mentioned  interfaces  plus  Report  Writer, 
Tell-A-Graf  (graphics  package),  and  the  Data  Definition 
Language. 

25.  Total 


In  a  survey  conducted  by  Cincom  Systems,  Inc.,  Total 
was  shown  to  be  integrated  into  an  average  of  417.  of  all 
user  applications.  This  makes  Total  the  most  widely  used 
DBMS  by  a  margin  of  almost  two-to-one  over  the  next  leading 
system.  Total  operates  on  28  different  computers  on  40 
separate  operating  systems.  It  is  designed  to  accommodate 
future  hardware  changes  and  promote  distributed  processing. 

Data  base  creation  can  be  done  via  user  application 
programs  or  optional  data  base  administrator  utilities. 
Access  methods  are  dependent  on  hardware.  Adding  new 
elements  or  paths  requires  data  base  regeneration  but  not 
necessarily  program  modification.  Application  programming 
can  be  done  using  COBOL,  PL/ I,  or  FORTRAN. 

Two  recovery  types,  point-of -f ai lure  and  full 
system,  can   be  accomplished   by  applying   before  images   in 
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reverse  order  to  the  latest  checkpoint.  Full  DBA 
capabilities  to  control  user  access  includes  subschema  which 
specifies  user  password,  usable  data  item  names,  and  file 
access.   Deadlock  is  controlled  by  a  DBA  specified  time-out. 
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IV-  THE  DATA  DICTIONARY 

A.   CONCEPT 

By  nature,  database  processing  involves  the  sharing  of 
resources.  A  DBMS  has  the  advantages  of  space  savings, 
increased  processing  speed,  and  enhanced  data  integrity  as  a 
result  of  this  sharing.  Nevertheless,  as  a  database  grows, 
many  of  the  advantages  can  be  negated  by  poor  programming 
discipline  and  data  standards.  If  programmers  continue  to 
code  unnecessary  new  procedures  with  unique  element  names 
for  each  new  application,  the  database  can  suffer  from  data 
redundancy.  This  can  cause  a  system  to  become  more 
difficult  and  expensive  to  maintain.  This  shared  data  must 
be  protected  through  standardization  to  ensure  data 
integrity  and  maximise  management  control.  At  NPS,  the  only 
standards  are  those  imposed  by  the  programmers  themselves. 
A  standard  name,  format,  and  relationship  for  every  entry  in 
the  data  base  must  be  established.  This  is  the  basic 
premise  behind  a  data  dictionary.  It  is  simply  a  way  to 
accumulate,  update,  and  report  information  about  data.  As  a 
minimum,  the  data  dictionary  should  give  the  names,  type, 
length  and  description  of  all  data  items  in  use.  Users 
should  be  restricted  to  only  those  representations  in  the 
dictionary.   If  a  piece  of  data  is  defined  in  more  than   one 
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area,  a  need  for  multiple  processes  to  update  this  data 
arises. 

Initial  implementation  of  a  data  dictionary  may  require 
extensive  data  modification.  Many  large  data  base  systems 
have  several  thousand  unique  data  items.  The 
inter-departmental  coordination  required  to  standardize, 
define  and  name  these  data  items  is  difficult  at  best.  The 
Data  Base  Administrator  (DBA)  is  responsible  for  setting 
standards  and  often  encounters  resistance  from  programmers 
and  users.  The  longer  NPS  delays  in  appointing  a  formal  DBA 
with  authority  to  establish  and  maintain  standards,  the 
harder  the  process  will  become.  In  the  initial  stages  of 
standardization,  the  programmers  and  users  can  feel  limited 
or  hindered  in  their  normal  routine.  They  must  learn  a  new 
set  of  rules  and  comply  with  them.  In  their  minds,  these 
new  standards  are  just  something  to  make  the  DBA ' s  job 
easier  at  the  expense  of  their  own.  Sometimes,  their 
feelings  are  somewhat  justified.  If  the  data  dictionary  is 
simply  used  to  store  information  about  data  without 
rigorously  enforced  data  administration  standards,  the  only 
advantage  will  be  the  ability  to  produce  reports  that 
document  redundant  processes  and  data. 

The  goal  of  a  data  dictionary  is  not  merely  to  document 
all  the  data  items  contained  in  a  database,  but  to  allow 
access  to  all  corporate  knowledge.  A  data  dictionary  can 
span  programs  and   databases.   It   may  include  entity   types 
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from  fields  and  formats  to  memos  and  relevant  publications. 
It  provides  programmers  and  users  with  a  bridge  to 
facilitate  communication  during  application  program 
development.  By  simplifying  the  development  process,  the 
user  can  become  more  involved  in  system  design,  thereby 
reducing  the  demand  on  programmers  and  programming  backlog 
at  NPS.  CRef.  7: pp.  89-953 

A  data  dictionary  is  in  fact  a  data  base  about  data 
bases.  Consequently,  it  must  either  be  dependent  on  a  DBMS 
or  contain  many  of  the  same  components.  Among  the  most 
important  components  of  a  DBMS  as  well  as  a  data  dictionary 
are  the  languages  necessary  for  query,  data  manipulation, 
and  data  definition. 


*  Data  Definition  Language  (DDL).  Language  for  defining 
type,  format  and  length  of  data  dictionary  entries. 
Data  entry  validation  may  be  based  on  definition. 

*  Data  Manipulation  Language  (DML).  English-oriented, 
on-line  or  batch  language  for  inserting,  changing  and 
deleting  entries  and  relationships.  Also  used  for 
accessing  and  obtaining  reports  of  entities  and  related 
entities.  A  set  of  macroinstructions  or  call  statements 
provided  by  a  particular  DD/DBMS. 

*  Query  Language  (QL) .  User  oriented  DML  directed  mainly 
at  interactive  ad  hoc  requests. 

*  Utilities.  Commands  for  loading,  recovery,  source 
language  code  generation,  interfacing  to  other  software 
products,  scanning  source  code  for  data  dictionary 
entries,  etc. 

*  Report  Writer.  Formatting  commands  for  high  volume 
printed  reports  of  entries  and  related  entries. 

*  Host  language  Interface.  Allows  the  programmer  to 
access  DBMS  files  through  calls  in  a  host  language. 


61 


*  Communication.   Link  between  micro  and  mainframe  for  th« 
purpose  of  sharing  data. 


While  these  high  level  languages  constitute  the  data 
dictionary  system,  information  about  data  called  metadata  is 
what  makes  up  the  data  dictionary  data  base.  Some  of  the 
possible  attributes  of  entries  in  a  data  dictionary  data 
base  are  listed  below. 

*  Attribute  name  and  synonyms 

*  Authorization  password (s)  for  retrieval,  update,  delete, 
etc. 

*  Data  type  and  format 

*  Range  of  values  that  may  be  stored 

*  Units  in  which   the  entity  is   represented,  e.g.,   feet, 

meters 

*  Name  of  other  entities   that  may  initialize,  update,   or 
delete  the  data  value 

*  Programming  language(s)  for  which  it  is  written 

*  Status,  i.e.  if  the   entity  is  in  development,   testing, 
damaged  or  production  status 

*  Text  (any  text  or  comments  may  be  written) 

Layered  above  the  dependent  or  independent 
implementation  of  a  data  dictionary  is  its  functional 
ability  to  interact  with  a  DBMS.  A  data  dictionary  is 
considered  active  if  programs  and  processes  depend  on  it  for 
their  metadata.  A  passive  data  dictionary  is  usually 
embedded  within  another  system  and  therefore  dependent  on 
that  system.    An   active  data   dictionary  can   be   embedded 
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within  another  system  or  completely  independent  with 
interfaces  to  many  different  systems.  Its  primary  functions 
include  identifying,  locating,  controlling,  reporting,  and 
manipulating  metadata.  With  a  completely  active  dictionary, 
users  interface  with  the  DBMS  only  through  the  dictionary. 
The  scope  of  the  activity  varies,  and  a  fully  active  data 
dictionary  does  not  yet  exist. 

B.   COMMERCIAL  DATA  DICTIONARY  SYSTEMS 

Data  dictionary  systems  have  evolved  recently  and  become 
an  increasingly  useful  tool  for  Data  Base  Administrators, 
auditors,  systems  analysts,  programmers  and  users.  In  many 
organizations  where  data  bases  and  information  systems 
achieve  a  high  degree  of  evolution  and  sophistication,  the 
data  dictionary  becomes  a  practical  necessity.  NPS  has  a 
large  number  of  potential  data  intensive  applications  well 
suited  for  a  data  base  environment.  It  is  plausible  to 
assume  that  NPS  could  become  increasingly  dependent  on  a 
data  base  and  information  system.  The  data  dictionary  is  a 
specialized  data  base  management  system,  or  application  of 
an  existing  DBMS.  The  data  base  is  a  repository  of 
descriptive  information  about  the  data  bases,  programs  and 
other  entities  associated  with  information  systems  practice. 
There  are  two  types  of  data  dictionary  systems,  dependent 
and  independent.    An  independent  DD   is  self-contained   and 
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has  its  own  reporting  and  maintenance  programs.  A  dependent 
data  dictionary  is  usually  implemented  as  an  application  of 
a  DBMS  and  is  dependent  on  that  particular  DBMS  to  -function. 

1  .  Independent 

DBMS  vendors  are  now  marketing  data  dictionaries 
with  growing  capabilities  for  use  specifically  within  their 
DBMS  environments.  However,  some  vendors  who  do  not  market 
a  DBMS  have  developed  data  dictionaries  to  be  nearly 
self-standing,  that  is,  they  do  not  require  the  use  of  a 
DBMS.  At  the  same  time,  such  products  have  interfaces  to 
generate  data  descriptions  specific  to  many  popular  DBMSs. 
The  price  range  varies  from  about  $15,000  to  *40,000 
depending  on  the  particular  vendor,  version  of  the  system 
and  options  included.  Table  3.1  summarizes  the  interface 
capabilities  of  several  of  the  major  data  dictionary 
systems.  Data  Catalog  2  and  Datamanager  are  the  only  two 
listed  that  can  be  considered  free-standing  or  independent. 
The  choice  is  arbitrary  and  should  not  be  interpreted  as 
indicative  of  the  author's  preferences  nor  overall  product 
ratings.  Information  provided  in  Table  VIII  was  derived 
from  CRef.  8D. 

2.   DBMS  Dependent 

A  dependent  data  dictionary  is  more  often  than  not  a 
commercially  available   package,   designed   for   a   specific 
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TABLE  VIII 

COMMERCIAL  DATA  DICTIONARIES 

+ + 

SUPPLIER     I      NAME      I   DBMS  REQ. 

+ + 


DBMS  USED 


CULL I NET 


!  IDD  I 

I  (INTEGRATED  I 

I  DATA  DICT-  I 

i  IONARY)  I 


IDMS 


IDMS 


IBM  CORP. 


I  DB/DC  DATA 
I  DICTIONARY 
I   SYSTEMS 

•+ 


IMS  or  DL/1 


IMS 


MANAGEMENT 
SYSTEMS  AND 
PROGRAMMING 
LTD. 


DATAMANAGER 


NONE 


IDMS 

TOTAL 

IMS 

ADABAS 

SYSTEM  2000 


TSI 
INTERNATIONAL 


IDATA  CATALOG  21 


NONE 


IMS 

TOTAL 

ADABAS 

DMS-1100 

DATA  MANAGER 


UN I VAC 


i 
+- 


I   DATA  DICT- 
I   IONARY (DDS) 


DMS-1100 


DMS-1100 


DBMS.  The  FOCUS  Data  Dictionary  (FOCUSDD)  is  itself  a  FOCUS 
data  base  and  is  considered  DBMS  dependent.  To  an 
organization  that  only  uses  one  DBMS,  a  dependent  data 
dictionary  can  be  an  advantage.  For  example,  FOCUSDD  can 
use  all  FOCUS  capabilities  directly  to  analyze  its  contents 
and  perform  ad  hoc  analysis.  Users  need  only  learn  one 
system  versus  two  with  an  independent  data  dictionary. 
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The  FOCUS  Data  Dictionary  (FOCUSDD)  is  a 
comprehensive  data  management  tool  that  can  monitor, 
control,  and  audit  applications.  It  serves  as  a  central 
repository  for  the  information  on  all  elements  of  FOCUS 
systems.  The  following  highlights  were  summarized  from 
CRef.  9:pp.  1-73. 


*  Menu-driven  operations 

FOCUSDD  is  an  online,  menu  driven  system.  It  is 
built  around  a  MAIN  MENU  listing  four  basic  optionsi 
Information  Processing,  Basic  Reporting,  System 
Maintenance,  and  entrance  into  FOCUS  for  ad  hoc 
analysis.  The  first  three  options  on  the  MAIN  MENU  lead 
to  a  sub-menu,  which  in  turn  breaks  out  into  detailed 
menus  providing  a  full  range  of  options. 

*  Analysis  of  Master  File  and  FOCEXEC  informations 

The  FOCUS  Data  Dictionary  analyzes  FOCUS  Master 
Files,  FOCEXECs,  COBOL  programs,  and  CMS  EXECs.  It 
records  information  for  fields,  files,  input/output  data 
sets  and  program  CALLs  used.  After  analyzing  a  Master 
File,  it  posts  information  regarding  Masters,  segments, 
cross-referenced  segments  and  data  fields  into  the 
dictionary.  For  FOCEXECs  and  other  supported 
procedures,  it  generates  cross-referenced  reports 
listing  referenced  fields,  system  commands,  and 
input/output  data  sets  used.  Analysis  can  be  done  on  an 
individual  file  or  group  of  files. 

*  Resource  accounting  facilitiess 

This  feature  captures  and  maintains  system  resource 
utilization  statistics  for  FOCEXECs  by  program.  As  a 
FOCEXEC  is  executed,  the  following  information  is 
collected  and  produced: 

-  Date  of  last  execution 

-  Total  number  of  executions 

-  USER ID  of  last  execution 

-  TOTAL  CPU  seconds 
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-  VIRTUAL  CPU  seconds 

-  Total  STARTIO  commands 

-  Total  CLOCK  TIME 

*  Automatic  dictionary  update  features 

An  automatic  Dictionary  Update  feature  provides 
facilities  for  automatically  posting  all  supported  file 
types  into  the  dictionary.  Updating  is  based  on 
mnemonic  values  stored  in  the  data  base  under  a  standard 
naming  convention  provided  by  FOCUSDD.  All  files 
containing  these  values  will  automatically  be  posted, 
analyzed,  and  updated. 

The  user  is  prompted  to  determine  whether 
information  about  Masters,  FOCEXECs  and  other  programs 
no  longer  in  existence  should  be  deleted  or  maintained. 

Menu-driven  procedures  for  full -screen  system 
maintenance  includes 

-  Program  description  query/update 

-  Field  description  update 

-  Program  deletion 

-  Master  File  description  update 

-  Master  File  deletion 

*  Program  change  log  facilitiess 

Provides  a  built-in  audit  trail  of  program  and 
system  modifications.  The  user  can  create,  query, 
update  or  delete  entries  to  the  Log.  This  allows  easy 
documentation  and  monitoring  of  all  changes. 

*  Automatic  generation  of  program  documentations 

For  each  program  in  the  dictionary,  a  formatted 
report  is  generated  which  displays  program  narrative  and 
an  input /output  list  including  data  bases  accessed, 
external  routines,  and  the  actual  source  listing. 

*  Comprehensive  set  of  standard  reportss 

A  built-in  series  of  sixteen  standard  reports 
display  all  available  information  on  programs,  data   and 
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their  relationships.  Report  selection  is  menu-driven, 
featuring  terminal  or  printed  report  generation.  Key 
reports  includes 

-  Catalogues  o-f  Master  Files/Programs 

-  FOCEXEC  listing  by  filename 

-  Keyword  string  query  by  FOCEXEC 

-  Program  calls/called  by  program 

-  Fieldname  string  query  by  filename 

-  Field  listing  by  FOCEXEC 

-  Resource  analysis  by  USERID  and  program 

FOCUSDD  is  completely  menu-driven.  It  provides 
facilities  for  information  storage,  analysis,  reporting, 
documentation  and  auditing.  It  can  perform  Software  Nesting 
Analysis,  resolve  calling  sequences  up  to  ten  levels  deep, 
and  provide  a  complete  "calls/called  by"  analysis  for  user 
specified  programs. 

The  DBA  is  provided  a  powerful  means  of  controlling 
applications  with  FOCUSDD ' s  Automatic  Dictionary  Update 
facility.  Using  standard  naming  conventions,  this  feature 
automatically  posts  all  supported  file  types  in  the 
dictionary. 

C.   BENEFITS 

The  major  benefits  of  a  data  dictionary  derive  from  its 
flexibility  to  accommodate  changes  and  its  centralised 
location.   To  successfully   implement  any  DDS,  a   commitment 
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to  the  design,  implementation,  and  proper  usage  is  necessary 
from  all  levels  of  management.  Programmers  must  restrict 
their  work  area  and  ensure  that  only  valid  and  authorized 
changes  are  made  to  the  system.  Lastly,  it  is  essential 
that  a  DBA  be  assigned  to  ensure  compliance  with  the  rules 
of  the  system.  CRef.  10: pp.  38-443 

Both  types  of  data  dictionaries  have  relative 
advantages.  An  independent  DD  can  ensure  consistency  of 
data  definitions  by  verifying  and  editing  all  data  entries 
before  storage.  A  dependent  dictionary  can  be  integrated 
into  an  existing  DBMS  environment  with  minimum  user 
disruption.  Also,  a  dependent  dictionary  can  be  useful  in 
the  case  where  all  data  is  stored  under  a  single  DBMS. 

There  is  no  question  that  the  stand-alone  DD  is 
potentially  more  powerful  than  the  dependent.  In  some 
situations,  such  as  multiple  DBMSs,  it  may  be  the  only  way 
to  maintain  centralized  control  of  data.  Considering  cost 
and  performance,  the  conclusion  to  be  drawn  is  that  the 
dependent  dictionary  is  more  appropriate  for  organizations 
with  existing  data  organized  around  a  single  DBMS.  The 
independent  dictionary  is  best  suited  for  system  start-up 
and  multiple  DBMS  organizations. 
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V.  ANALYSIS  AND  GENERAL  DESIGN 

A.   FOCUS  DESIGN  CONSIDERATIONS 

At  the  Naval  Postgraduate  School,  FOCUS  DBMS  is  used 
as  the  administrative  data  base  facility.  The  Office  of  the 
Director  of  Admissions  employs  two  programmer /analysts  to 
develop  application  programs  and  maintain  data  integrity. 
Due  to  the  large  investment  in  time  and  money  associated 
with  FOCUS,  the  Director  of  Admissions  was  predisposed  to 
its  use  for  new  applications.  A  formal  requirements 
analysis  was  not  conducted,  but  a  recommendation  to  purchase 
PC  FOCUS  was  made.  When  used  on  compatible  micro-computer 
hardware,  PC  FOCUS  would  reduce  the  amount  of  mainframe  CPU 
time  required.  Data  could  be  downloaded  to  a  personal 
computer  in  the  Director  of  Admissions  office  for 
manipulation  and  reporting.  Additionally,  application 
programs  could  be  generated  on  the  PC  and  executed  on  the 
mainframe  at  times  other  than  peak  load. 

FOCUS  is  based  on  the  hierarchical  model  in  which  a 
parent  segment  may  have  one  or  many  descendant  segments. 
The  child  is  limited  to  a  single  parent.  This  one-to-many 
relationship  is  denoted  in  diagrams  by  either  projected 
boxes  or  a  double  headed  arrow  connecting  parent  to  child. 
Solid  lines  are  used   to  infer  structural  relationships   and 
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dotted  lines   for   cross-reference   or   index   to   identical 
fields  in  other  segments. 

The   discussion  that   follows   is   based   on  information 
contained  in  CRef.  113. 

1 .   Data  Description  Language 

The  description  of  a  FOCUS  file  is  typed  into  a  CMS 
file  whose  filetype  is  MASTER.  The  CMS  filename  becomes  the 
name  by  which  the  file  is  known  to  FOCUS.  For  example,  the 
FOCUS  file  "STUDENTS"  must  have  a  file  description  stored 
with  a  CMS  filename  of  "STUDENTS  MASTER".  Three  classes  of 
attributes  are  used  to  describe  a  FOCUS  file.  They  are  file 
attributes,  segment  attributes,  and  field  attributes. 
Figure  5.1  below  gives  an  example  of  a  single  segment  master 
description. 


+ + .. + 

i  ;  : 

!  FILE  DECLARATION  I  FILENAME"      ,SUFFIX=  I 

+ + + 

:  i  i 

i  SEQ  DECLARATION   ! SEGNAME-       ,SEGTYPE=    , PARENT"      i 

+ + + 

■  >  ^ 

i  i  i 

I      DATA  OR        I  FIELDNAME-     , ALIAS"      , FORMAT"    ,*l 

I       FIELD         ! FIELDNAME"     , ALIAS"      , FORMAT"    ,*l 

I    DECLARATIONS    i FIELDNAME-     , ALIAS"      , FORMAT"    ,*l 

I  I  FIELDNAME"     , ALIAS"      , FORMAT"    ,*! 

+ + + 

Figure  5.1    Sample  Focus  Master  Description 
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Attributes  describing  the  file,  segments,  and  fields 
of  a  FOCUS  file  are  typed  in  free  form  comma  delimited 
format.  A  dollar  sign  <*)  signifies  the  end  of  the 
description  of  each  element  and  a  checking  procedure  can  be 
used  to  locate  typing  errors  and  rule  violations  before  to 
data  entry.  After  data  entry,  it  is  no  longer  possible  to 
make  arbitrary  changes  to  the  file  description.  Any  change 
to  the  master  file  that  necessitates  a  change  to  the 
physical  data  base  requires  reorganization  of  the  data. 
This  does  not  imply  weak  logical /physical  independence. 
Data  must  be  reconstructed  into  a  form  that  coincides  with 
the  master  description.  It  would  be  nice  if  FOCUS  would 
reindex  files  automatically.  Nevertheless,  the  REBUILD 
utility  provides  options  for  rebuilding  a  FOCUS  file, 
reorganizing  a  FOCUS  file,  and  for  indexing  fields  in  a 
FOCUS  file  after  data  entry. 

Both  static  and  dynamic  cross-referencing  of  files 
are  available  with  advantages  and  disadvantages  to  each. 
Static  cross  references  are  specified  in  the  master 
description  and  are  therefore  always  active,  but  require  the 
use  of  the  REBUILD  utility  to  change.  Dynamic 
cross-reference  is  accomplished  through  the  JOIN  command. 
It  does  not  take  up  file  space  by  being  pre-posi ti oned  in 
the  master  description  and  can  be  easily  invoked  when  needed 
to  link  an  entire  file  structure.  On  the  negative  side,  the 
JOIN  command  must   be  issued  during   each  session,  can   only 
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link  entire  file  structures,  and  is  slower  after  first  usage 
than  a  static  cross  reference. 

Prior  to  use  of  static  or  dynamic  cross-referencing, 
at  least  one  field  in  the  desired  segment  of  each  file  must 
be  of  type  "I"  or  indexed.  This  is  accomplished  through 
field  attributes  in  the  MASTER  file.  Any  number  of  fields 
may  be  indexed  on  a  segment,  although  only  those  which  have 
common  values  in  other  files  are  practical  candidates.  The 
presence  of  the  index  is  crucial  for  the  operation  of  the 
cross  reference  facilities.  Any  number  of  external  sources 
may  locate  and  thereby  share  a  segment  because  of  it. 

2 •  Data  Manipulation  Language 

Once  a  MASTER  file  has  been  constructed  and  found 
free  of  errors,  data  can  be  entered  into  a  FOCUS  data  base 
file.  A  non-procedural,  fourth  generation  data  manipulation 
language  is  used  for  all  phases  of  data  entry,  manipulation, 
and  reporting.  The  language  is  divided  into  two  functional 
areas  called  the  Transaction  Processor  and  the  Dialogue 
Manager.  The  purpose  of  the  transaction  processor  language 
is  to  facilitate  modification  of  information  in  a  FOCUS  data 
base  without  having  to  write  a  computer  program.  The 
transaction  processor  is  entered  by  typing  the  FOCUS  command 
MODIFY  followed  by  the  name  of  the  file  to  be  changed. 

The  transaction  processor  has  the  ability  to  accept 
input  in  several  forms.   FIXFORM  specifies  fixed  format  data 
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with  each  -field  appearing  in  a  set  position  of  the  record. 
When  FIXFORM  is  used  the  name  of  the  data  fields  and  the 
number  of  characters  to  be  processed  must  be  specified. 
Under  normal  usage  FIXFORM  does  not  specify  the  source  of 
the  data  input  transactions.  Instead,  the  subcommand,  DATA 
ON,  is  usually  placed  at  the  end  of  the  procedure.  The 
PROMPT  subcommand  specifies  that  the  user  will  enter  data 
interactively  in  response  to  prompts  from  FOCUS.  When 
PROMPT  is  used,  FOCUS  will  request  that  the  operator  type 
the  data  values  in  response  to  prompting  messages.  Only  one 
field  at  a  time  is  requested,  but  the  operator  has  the 
option  of  using  free  form  comma  delimited  format  to  input 
several  values  at  a  time.  FOCUS  will  then  skip  ahead  and 
resume  prompting  for  any  values  not  yet  entered. 
Preformatted  CRT  screens  for  f i 1 1 -in-the-blank  data  entry 
can  be  designed  using  the  CRTFORM  subcommand.  The  FREEFORM 
subcommand  can  be  used  to  alter  the  natural  order  of  data 
input  from  that  described  in  the  MASTER  file. 

The  basic  operation  during  transaction  processing  is 
to  match  values  from  a  transaction  to  corresponding  values 
in  a  data  base  and  take  action  depending  on  the  status  of 
the  match.  The  MATCH  subcommand  is  used  to  designate  fields 
to  match.  All  key  fields  in  each  segment  must  be  specified. 
Fieldnames  can  always  be  referenced  by  either  their  full 
fieldname,  alias,  or  shortest  unique  truncation.  The 
actions  to   be   taken   following  the   MATCH   subcommand   are 
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specified  through  the  ON  MATCH  and  ON  NOMATCH  subcommands. 
A  short  description  of  each  of  the  possible  actions  is  given 
below. 


REJECT 


UPDATE 


DELETE 


COMPUTE 


considered 


INCLUDE 


VALIDATE 


TYPE 

PROMPT 
FREEFORM 

CRTFORM 

FIXFORM 
CONTINUE 


The    transaction    is 

dupl icate. 

'}.  . 

If   a    match   is    found,   the 

specified  will  be  updated. 


fields 


60T0 


The  matched  record  segment,  all 
dependent  records,  references,  and 
indexes  &re   deleted. 

The  expressions  that  follow  may  refer  to 
transaction  values  or  data  base  values 
before  or  at  the  point  of  match.  These 
new  values  may  be  used  to  update  the 
data  base. 

A  data  base  record  is  to  be  included. 
This  is  the  basic  input  process. 

The  expressions   may  refer   to  the  same 

values  as  COMPUTE.   If  the  logic  of  the 

expression  evaluates  to  false,  the 
transaction  is  rejected. 

A  message  may  be  typed  in  response  to 
MATCH  or  NOMATCH  logic. 

Prompts  user  for  specified  fields. 

Additional  data  is  read  from  a 
transaction  file. 

Beginning  or  continuation  of 
f i 1 l-in-the-bl ank  CRT  screen. 

Same  as  FREEFORM 

This  is  the  default  option  when  a 
further  MATCH  subcommand  in  present,  but 
it  is  recommended  that  action  be  defined 
expl i  ci  tly . 

Unconditional  branch  to  named  CASE. 
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IF-GOTO         Conditional  branch  to  named  CASE. 

It  is  possible  to  store  FOCUS  transaction  processing 
commands  in  a  -File  -for  repetitive  use  or  execution  at  a 
later  time.  Any  CMS  filename  and  filetype  can  be  used  to 
store  the  procedure/  If  only  a  filename  is  provided,  a 
filetype  of  FOCEXEC  is  assumed  . 

With  the  Dialogue  Manager,  a  stored  procedure  may 
contain  variable  information  for  which  a  value  is  provided 
only  at  the  time  of  execution.  The  variables  can  be  used  to 
represent  data  as  numeric  constants,  dates,  or  to  conduct  a 
dialogue  by  prompting  the  operator  for  a  response.  The 
first  character  of  the  variable  must  be  an  ampersand. 

The  Dialogue  Manager  is  invoked  by  typing  the  FOCUS 
command  EXEC  followed  by  the  name  of  the  procedure. 
Together,  the  Dialogue  Manager  and  DDL  constitute  a 
semi -structured  programming  language.  Any  line  containing 
Dialogue  Manager  commands  or  GOTO  labels  must  begin  with  a 
dash.  The  EXEC  command  can  be  embedded  in  a  program  to  call 
another  module.  On  completion  of  the  called  module,  the 
Dialogue  Manager  returns  to  the  next  step  in  the  calling 
program. 

The  sequential  execution  of  one  Dialogue  Manager 
statement  after  another  can  be  altered  by  use  of  branching 
statements.  The  GOTO  command  can  be  used  separately,  in  an 
unstructured  mode,  to  branch  to  a  label  specified   elsewhere 
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in  the  program.  This  can  result  in  complicated  coding.  To 
eliminate  this  problem,  a  structured  programming  discipline 
must  be  maintained.  IF-GOTO  logic  and  labels  should  be  used 
only  -for  sequential  or  closed  loop  execution.  Branching  is 
most  often  used  to  test  the  values  of  prompted  variables  and 
then  select  the  procedure  to  be  executed. 

Several  other  commands  and  labels  are  frequently 
used.  Messages  can  be  typed  from  a  stored  procedure  on 
Dialogue  Manager  lines  beginning  with  the  label  -TYPE. 
Variables  may  be  embedded  in  the  text  of  the  line.  -EXIT, 
-QUIT,  and  -RUN  are  three  labels  used  to  control  the 
execution  and  return  characteristics  of  a  FOCUS  stored 
procedure.  Individual  lines  of  a  stored  procedure  are 
stacked,  awaiting  execution,  until  either  the  label  -EXIT  or 
-Run  is  encountered.  An  implied  -EXIT  exists  after  the  last 
line  in  a  procedure.  When  either  an  implicit  or  explicit 
-EXIT  is  encountered  processing  of  lines  in  the  procedure  is 
ended  and  execution  of  the  stacked  lines  begins.  Control  is 
returned  to  the  next  higher  program  level  or  native  FOCUS. 
With  -QUIT,  the  return  characteristics  are  the  same  but  the 
stacked  lines  are  not  executed.  The  -RUN  label  exits  the 
procedure  and  executes  the  stacked  lines.  Processing 
resumes  at  the  line  following  -RUN.  Table  IX  summarizes  the 
effects  of  the  three  labels. 
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+ + 

I  TABLE  IX  I 

I  I 

i  FOCUS  DIALOGUE  MANAGER  LABELS  I 

+ + + + 

I  LABEL   !  EXECUTES  STORED  LINES  I         RETURNS  TO  I 


I  -EXIT   i  YES  iNext  higher  program  level  I 

i  I  >  I      or  native  FOCUS      I 

+ + + + 

I  i  I  I 

I  -QUIT   i  NO  INext  higher  program  level ! 

II  I      or  native  FOCUS      I 

+ + + + 

li  I  I 

i  -RUN    I  YES  !    Line  following  -RUN    I 

+ + + + 


If  a  stored  module,  called  by  another  procedure, 
does  not  contain  an  -EXIT  label  or  an  END  command,  the 
terminal  will  remain  open  for  interactive  processing.  When 
processing  or  queries  are  complete,  the  user  enters  QUIT  to 
return  to  the  calling  procedure.  This  technique  is  used  in 
the  design  of  the  data  dictionary  discussed  later  in  this 
chapter. 

B.   DATA  DICTIONARY 

During  the  design  phase  of  any  modular  application, 
standard  interfaces  are  specified.  This  can  be  accomplished 
through  communication  between  programmers  to  identify 
parameter  passing  requirements  such  as  global  variables. 
Verbal  communication  is  often  time  consuming,  error  prone, 
and  confusing.     Another   method   for   standardization   and 
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control  is  the  data  dictionary.  Using  this  method,  the  DBA 
can  specify  what  data  elements  and  relationships  are 
available  for  programmer's  use.  The  use  of  a  data 
dictionary  during  the  program  design  phase  is  one  specific 
application   of  standardization  and  sharing. 

In  some  circles,  a  data  dictionary  is  considered  to  have 
only  limited  benefits  during  the  development  of  new  data 
processing  systems.  The  real  benefit  is  in  the  reduction  of 
maintenance  costs  CRef.  7:p.  90].  The  dividing  line  between 
development  and  maintenance  is  arbitrary.  It  is  sometimes 
hard  to  say  when  development  ends  and  maintenance  begins. 
An  explanation  for  this  opinion  is,  when  compared  to  the 
vast  benefits  gained  during  the  remainder  of  the  system  life 
cycle,  development  is  only  a  small  percentage  of  the  effort. 
Whatever  the  explanation,  the  judgment  is  in  error:  "A  data 
dictionary  can  be  of  particular  value  to  systems 
analysts/designers  in  the  three  phases  of  system 
development:  (1)  analysis,  (2)  design,  and 
(3)  implementation."  CRef.  10:p.  105]  It  is  acknowledged  in 
Government  and  private  industry  that  an  increase  in 
productive  time  and  money  expended  during  software 
development  can  significantly  reduce  total  life  cycle  costs. 

A  data  dictionary  can  be  an  invaluable  aid  during 
applications  program  development.  However,  not  all 
functions  of  the  FOCUS  DATA  DICTIONARY,  described  in  Chapter 
3,  are  required  or  even  useful  during  the  development  stage. 
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The  most  beneficial  dictionary  -functions  to  a  programmer  are 
listed  below. 


*  reports   which   display   all   available   information   on 
programs,  data,  and  their  relationships 

♦  automatic  dictionary  update  -for  new  or  changed  Masters 
and  FOCEXECs.    > 


Reports  which  display  information  on  data  and  their 
relationships  can  yield  many  benefits.  This  one  function 
can  reduce  data  redundancy  and  develop  standards  by 
providing  the  system  designer  with  current  data  descriptions 
and  naming  conventions. 

It  is  possible,  with  the  FOCUS  4GL ,  to  implement  these 
useful  functions  without  the  expense  of  a  commercial  data 
dictionary  package.  Nevertheless,  a  basic  system 
development  dictionary  would  not  be  of  much  use  during  later 
life  cycle  stages. 

1 .   Planning 

It  is  necessary  to  plan  the  scope  and  objectives  of 
a  data  dictionary  before  construction  can  begin.  Here,  the 
purpose  of  the  dictionary  is  to  aid  in  the  development  of 
application  programs.  The  primary  objective  is  the 
interactive  cross-referencing,  verifying,  and  updating  of 
data  about  data.  A  programmer  who  is  able  to  determine 
existing  relationships  and  names  from  a  data  dictionary  will 
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be  able  to  make  use  of  those  relationships  and  standard 
naming  conventions. 

The  proposed  system  is  narrow  in  scope.  It  is 
designed  as  a  FOCUS  DBMS  dependent  application.  Features 
include  ad  hoc  query  capability,  standard  reports  on 
metadata,  and  dictionary  maintenance. 

Although  automatic  dictionary  updates  are  useful  to 
the  programmer,  they  are  considered  non-essential  in  this 
case.  A  description  of  how  to  implement  an  automatic  update 
feature  is  given  in  the  design  phase. 

2.   Requirements  Definition 

The  outputs  from  the  design  data  dictionary  include 
the  following. 

*  FOCUS  file  definitions/descriptions 

*  Segment  definitions/descriptions 

*  Field  description/alias 

*  FOCUS  file  summary  report 

*  FOCUS  EXEC  descriptions 

*  Variable  names/descriptions 

*  Called/Called  by  analysis 
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The  FOCUS  file,  segment,  and  -field  descriptions  and 
summary  report  are  used  to  determine  where  and  how  data  is 
stored.  All  the  information  contained  in  these  reports, 
with  the  exception  of  the  narrative  description,  can  be 
gleaned  from  the  FOCUS  Master  Description. 

The  file  description  contains  the  file  name,  a 
narrative  description,  file  type,  and  number  of  segments. 
In  addition,  the  individual  or  organization  responsible  for 
maintenance  on  the  file  is  listed.  The  same  type 
information  is  contained  in  the  segment  and  field  reports. 

Details  on  FOCUS  EXECs  are  contained  in  variable, 
FOCUS  EXEC,  and  called/called  by  reports.  The  FOCUS  EXEC 
report  is  a  quick  reference  to  determine  the  purpose  of 
named  EXECs.  A  simple  naming  convention  is  imposed  through 
compliance  with  a  standard  prefix-postfix  routine.  The 
prefix  identifies  EXEC  purpose  and  the  postfix  specifies  a 
type.  For  example,  if  the  purpose  of  an  EXEC  were  to  add 
file  information,  it  would  be  named  ADDFILE.  If  the  purpose 
were  to  delete  EXEC  information,  it  would  be  named  DELEXEC. 
The  called/called  by  analysis  can  be  used  to  determine  the 
impact  of  a  change  to  a  specific  EXEC. 

The  ability  to  add,  change,  or  delete  items  in  the 
dictionary  is  called  dictionary  maintenance.  It  is 
accomplished  through  a  menu  driven  utility  for  either  FOCUS 
files  or  EXECs. 
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Ad  hoc  queries  can  be  made  two  ways.  First,  by 
exiting  the  dictionary  and  returning  to  native  FOCUS,  the 
DML  can  be  used  to  make  queries.  The  disadvantage  is  that 
knowledge  of  data  structures  is  required  to  execute  dynamic 
joins.  The  second  method  is  to  make  the  menu  selection  that 
best  answers  the  query,  then  at  the  end  of  execution,  make 
the  ad  hoc  query  prior  to  entering  quit.  This  technique  was 
discussed  earlier  in  this  chapter  under  the  Dialogue 
Manager. 

3.   Design 

Table  X  contains  the  data  necessary  to  meet  the 
requirements  above.  Two  FOCUS  Master  Files,  shown  in 
Table  XI,  were  defined  using  these  data  elements. 


TABLE  X 
DICTIONARY  DATA  ELEMENTS 
FOCUS  EXECS  MASTER  FILES 


FOCUS  EXEC  name 
EXEC  purpose 
Variable  name 
Variable  format 
Variable  description 
File  used  by  EXEC 
EXEC  called  by  EXEC 


Master  File  name 

File  type 

File  description 

Segment  name 

Segment  parent 

Segment  type 

Segment  description 

Field  name 

Al  i  as 

Field  format 

Field  type 

Field  description 

key 
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TABLE  XI 
FOCUS  DESIGN  DICTIONARY  MASTER  FILES 

FOCUS  'MASTER  FILE  EDICTION 


F I LENAME-ED I CT I ON , SUFF I X-FOC 

SEGNAME-EXECS , SEGTYPE-S1 

FIELDNAME»EXEC_NAME    ,ALIAS«EN   ,F0RMAT»A8   ,* 
FIELDNAME-PURPOSE      , ALI AS=D0ES,F0RMAT=A25   ,* 

SEGNAME-VAR I ABLE , PARENT-EXECS , SEGTYPE=S 1 

FIELDNAME=VAR_NAME  ,ALIAS=VN  ,F0RMAT=A8  ,* 
FIELDNAME»VAR_FORMAT  , ALIAS=VFMT,F0RMAT-A5  ,* 
F I ELDNAME=V AR_DESCR I PT , AL I AS-VDES , F0RMAT-A25   , * 

SEGNAME-F I LE_NAM, PARENT-EXECS, SEGTYPE-S1 

FIELDNAME=FILE_NAME    ,ALIAS»FLN  ,F0RMAT=A8   , TYPE- I,* 

SEGNAME-CALLED, PARENT-EXECS, SEGTYPE-S1 

FIELDNAME=CALLED_EXEC  ,ALIAS=CE   ,F0RMAT=A8    ,* 

FOCUS  MASTER  FILE  FDICTION 


FILENAME=FDICTION,SUFFIX=FOC 

SEGNAME=F I LES , SEGT YPE=S 1 

FIELDNAME=FILE_NAME    ,ALIAS=FLN  ,F0RMAT=A8  , TYPE- I,* 

FIELDNAME=FILE_TYPE    , ALI AS=FTYP ,F0RMAT=A3  ,* 

FIELDNAME=NUM_SEGS     ,ALIAS=NS   , FORMAT- II  ,* 

F I ELDNAME-F I LE_DESCR I P , AL I AS-FDES , F0RMAT-A25  , * 

FIELDNAME=MAINTAINE_BY,ALIAS=FMAN,FORMAT=A12  ,$ 

SEGNAME-SEGMENTS , PARENT-FILES , SEGTYPE-S1 

FIELDNAME»SEG_NAME     , ALIAS=SEGN,F0RMAT=A8  ,* 

FIELDNAME=CHILD_OF     , ALI AS-SPAR ,F0RMAT=A8  ,* 

FIELDNAME=SEG_TYPE     , ALI AS-STYP ,F0RMAT=A3  ,* 

FIELDNAME=SEG_DESCRIPT,ALIAS=SDES,F0RMAT=A25  ,* 

SEGNAME-F I ELDS , PARENT-SEGMENTS , SEGT YPE-S 1 

FIELDNAME=FIELD_NAME   ,ALIAS=FDN  ,F0RMAT=A12  ,* 

FIELDNAME-ALTERNATE    , ALIAS-ALT  ,F0RMAT=A4  ,* 

FIELDNAME=FIELD_F0RMAT,ALIAS=FFMT,F0RMAT=A5  ,* 

FIELDNAME=FIELD_TYPE   , ALI AS-FDTP, FORMAT-A1  ,* 

FIELDNAME-KEY           , ALIAS-     ,FORMAT=Al  ,* 

FIELDNAME=FIELD_DESCRI , ALI AS-FDDE , F0RMAT-A25  ,* 
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Figures  5.2  and  5.3  depict  the  logical  FOCUS  structures 
derived  from  the  Master  Files,  which  comprise  the  data 
storage  structures  for  the  dictionary.  FOCUS  source  code 
for  the  data  dictionary  and  sample  reports  are  contained  in 
Appendix  A. 

FOCUS  has  the  ability  to  read  files  other  than  those 
it  creates  itself.  A  comma  delimited  file  is  one  in  which 
individual  fields  are    separated  by  a  comma.   A  FOCUS   Master 


EXECS 

01  SI 

************** 

*EXEC_NAME    ** 
♦PURPOSE      ** 

*  ** 

*  ** 

*  ** 
*************** 

************** 

I 

+ 

I 

I  VARIABLE 

02  I  SI 
************** 
*VAR_NAME     ** 
*VAR_FORMAT   ** 
*v-AR_DESCRIPT** 

*  ** 

*  ** 
*************** 

************** 


+ 

I 

I  FILE_NAM 
03     I  SI 

************** 
*FILE_NAME    **I 

*  ** 

*  ** 

*  ** 

*  ** 
*************** 

************** 


I  CALLED 
04     I  SI 

************** 
*CALLED_EXEC  ** 

*  ** 

*  ** 

*  ** 

*  ** 
*************** 

************** 


Figure  5.2    Structure  of  Focus  File  Ediction 
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FILES 

01  SI 

************** 
*FILE_NAME    **I 
*FILE_TYPE    ** 
*NUM_SEGS     ** 
*FILE_DESCRIP** 

*  ** 
*************** 
************** 

I 
I 
I 
I  SEGMENTS 

02  I  SI 
************** 
*SEG_NAME     ** 
*CHILD_0F     ** 
*SEG_TYPE     ** 
*SEG_DESCRIPT** 

*  ** 
*************** 

************** 
I 
I 
I 
I  FIELDS 

03  I  SI 
************** 
*FIELD_NAME   ** 
♦ALTERNATE    ** 
*FIELD_F0RMAT** 
*FIELD_TYPE   ** 

*  ** 
*************** 

************** 


Figure  5.3    Structure  o-f  Focus  File  Fdiction 

File  is  designed  as  a  comma   delimited  -File  and  as  such   can 
be  read  directly  by  FOCUS. 
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The  design  data  dictionary  in  Appendix  A  can  be  made 
partially  active  by  taking  advantage  0+  FOCUS  Master  Files 
comma  delimited  form.  If  the  dictionary  Master  File  were 
assigned  a  file  type  of  external,  data  from  individual 
Master  Files  already  in  existence  could  be  made  available  to 
the  user.  This  would  alleviate  the  need  to  enter 
information  into  the  dictionary  which  is  already  contained 
in  a  Master  File.  FOCUS  also  makes  provisions  for  a 
narrative  description  within  a  Master  File. 

Further  attempt  to  activate  the  design  dictionary 
is  not  recommended.  The  inhouse  development  of  an  active 
data  dictionary  can  be  a  costly  and  time  consuming  process. 
The  Director  of  Admissions  Office  does  not  have  the  assets 
available  to  accomplish  that.  It  is  recommended  that  a  Data 
Base  Administrator  be  assigned  from  the  Director  of 
Admissions  Office  and  that  the  FOCUS  Data  Dictionary  be 
purchased  and  implemented. 

C.   TRANSCRIPT  SUMMARY  APPLICATION 

The  planning  and  requirements  phase  of  the  transcript 
summary  application  were  covered  in  Chapter  2.  Table  XII 
lists  the  FOCUS  Master  File  descriptions.  The  resulting 
logical  structures,  shown  in  Figures  5.4,  5.5,  and  5.6,  were 
dictated  by  the  characteristics  of  the  external  files 
supplied  by  the  Naval  Academy. 
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TABLE  XII 
TRANSCRIPT  SUMMARY  APPLICATION  MASTER  FILES 

FOCUS  MASTER  FILE  ADM I SS 10 


FILENAME=ADMISSIO,SUFFIX=FOC 
SEGNAME=STUDENT , SEGTYPE-S1 

F I ELDNAME=STUD_ I D 

FIELDNAME=STUD_NAME 

FIELDNAME=SOC_SEC_NUM 

FIELDNAME=MAJOR 

FIELDNAME-SEX 

FIELDNAME-NATIONALITY 
SEGNAME-COURSE , SEGTYPE-S1 

FIELDNAME-COURSE_ID 

F I ELDNAME=LETTER_GRADE , AL I AS-LG   , F0RMAT-A2 

F I ELDNAME-SEMESTER     , AL I AS-WHEN , F0RMAT=A3 

FOCUS  MASTER  FILE  AVAIL 


, ALIAS-SID 

,F0RMAT=A7 

,* 

,ALIAS=SN 

,F0RMAT=A17 

,* 

,ALIAS=SSN 

,F0RMAT=A10 

,* 

, ALIAS-MA J 

,F0RMAT=A4 

,* 

,ALIAS=SEX 

,F0RMAT»A2 

,* 

, ALIAS-RACE 

,F0RMAT=A8 

,* 

,ALIAS=CID 

,F0RMAT=A6 

,* 

F I LENAME-AVA I L , SUFF I X=FOC 

SEGNAME=DESCRIPT,SEGTYPE=S1 

FIELDNAME=COURSE_ID    ,ALIAS=CID  ,F0RMAT=A6   , TYPE- I,* 
FIELDNAME=CREDIT_H0URS,ALIAS=CHRS,F0RMAT=I1    ,* 

FOCUS  MASTER  FILE  REQ 


F I LENAME-REQ , SUFF I X-FOC 

SEGNAME-DESCR I PT , SEGTYPE-S 1 

FIELDNAME=COURSE_ID    ,ALIAS-CID  ,F0RMAT=A6   ,TYPE=I,*i 
FIELDNAME=SUBJ_AREA    ,ALIAS=SA   ,F0RMAT=A7    ,*       I 


The  source  code  and  sample  output  -for  a  prototype 
application  that  summarizes  transcript  information  are  given 
in  Appendix  B.  The  prototype  can  be  modified  to  read  data 
from  the  fixed  format  external  file  described  in  Chapter  2. 
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STUDENT 
01       SI 

************** 
*STUD_ID  ** 
*STUD_NAME  ** 
*S0C_SEC_NUM  ** 
♦MAJOR  ** 
4  ** 

*************** 
************** 

I 

I 

I 

I  COURSE 
02     I  SI 
************** 
*COURSE_ID    ** 
*LETTER_GRADE** 
♦SEMESTER     ** 

*  ** 

*  ** 
*************** 

************** 


Figure  5.4    Structure  of  Focus  File  Admissio 

The  external  -file  contains  a  group  of  adjacent  fields  that 
are  repeated  in  the  same  record.  (ie.  Course  information  is 
repeated  numerous  times  for  each  student.)  Such  a  structure 
can  be  described  to  FOCUS  by  assigning  the  non-repeating 
portion  to  one  segment,  and  the  repeating  group  to  another, 
which  is  its  descendent.  By  assigning  a  Segment  attribute 
of  VARIABLE  to  the  repeating  group,  FOCUS  is  informed  that 
the  length  of  the  physical  external  file  varies.   The  number 
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DESCRIPT 
01       SI 

************** 
*C0URSE_ID    **I 
*SUBJ_AREA    ** 

*  ** 

*  ** 

*  >  ** 
*************** 

************** 


Figure  5.5    Structure  of  Focus  File  Req 


DESCRIPT 
01       SI 

************** 
*C0URSE_ID    **I 
*CREDIT_H0URS** 

*  ** 

*  ** 

*  ** 

*************** 
************** 


Figure  5.6    Structure  of  Focus  File  Avail 

o-f  occurrences  of  the  repeating  group  is  then  determined  for 
each  record  by  dividing  the  number  of  characters  read  by  the 
length  of  the  repeating  segment.  Since  the  prototype  was 
designed  using  the   same  logical   structure  as   that  of   the 
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external   file,   this   modification   would   not   necessitate 
changes  to  program  logic. 


>  ; 
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VI.  CONCLUSIONS 

A.    IDENTIFICATION  OF  NEED 

Because  of  the  size  of  the  programming  staff  in  the 
Office  of  the  Director  of  Admissions  and  the  limited  scope 
of  present  FOCUS  application  programs,  it  might  be  concluded 
that  a  data  dictionary  is  not  required.  Nevertheless,  now 
is  the  time  to  implement  a  DDS.  The  Administration  has 
already  embraced  the  DBMS  approach  and  the  programming 
backlog  is  increasing.  The  longer  implementation  is 
delayed,  the  greater  the  chance  that  data  redundancy  and  the 
loss  of  data  integrity  will  erode  system  credibility.  In 
addition,  programmer  response  time  to  new  applications  may 
increase  because  of  the  maintenance  effort  required  for 
existing  applications. 

One  major  benefit  of  a  46L  DBMS  like  FOCUS  is  its 
ability  to  narrow  the  gap  between  users  and  programmers.  As 
users  become  more  familiar  with  the  system,  they  should  be 
able  to  develop  application  programs  of  their  own.  This 
should  result  in  a  reduction  of  the  programming  backlog.  On 
the  other  hand,  with  this  new  found  familiarity  with  the 
system,  management  might  envision  and  request  more  program 
development.    A  properly   implemented  and   maintained   data 
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dictionary  can  aid  in   programmer  effectiveness  and   provide 
management  with  more  effective  control  over  data. 

B.   BENEFITS 

Even  the  most  basic  form  of  a  data  dictionary,  when 
properly  implemented,  can  be  of  great  use  during  the  program 
development  cycle.  Conversely,  poor  design,  implementation, 
or  use  will  make  problems  like  data  integrity  and  redundancy 
even  worse. 

The  major  benefits  derived  from  use  of  the  data 
dictionary  (Appendix  A)  during  the  design  phase  of  the 
transcript  summary  application  (Appendix  B)  are  listed 
below: 

*  Reduced  data  redundancy 

*  Enhanced  data  integrity 

*  Documentation  of  existing  relationships 

*  Simplified  system  maintenance 

*  Highlighted  standard  naming  conventions 

*  Provided  data  element  reference 

Benefits  derived  from  a  data  dictionary  are  proportional 
to  its  size.  Since  the  transcript  summary  program  spanned 
only  three  FOCUS   files,  it   is  hard   to  say   that  the   data 
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dictionary  provided  any  great  advantage.  Nevertheless, 
access  to  data  elements  and  their  logical  structure  enhanced 
the  programmer's  ability  to  locate  and  reduce  data 
redundancy. 

Implementation  of  a  data  dictionary  requires  the 
standardization  of  data  items.  For  a  large  existing  system 
in  an  organization  with  multiple  departments,  this  can  be 
complex.  Even  in  the  simple  application  discussed  here,  the 
standardization  o-f  data  items  greatly  contributes  to  long 
range  data  integrity. 

During  the  design  of  the  transcript  application, 
information  on  which  programs  use  the  same  data  type  and  how 
they  relate  was  required.  This  is  in  essence  a  limited  view 
of  the  logical  data  structure  and  relationships.  It  is 
required  for  the  proper  access  of  required  data,  using 
dynamic  joining  when  necessary. 

Maintenance  can  be  defined  many  ways.  Regardless  of 
whether  it  is  considered  as  modifications  after  delivery  or 
after  the  first  successful  execution,  the  benefits  of  the 
data  dictionary  are  the  same.  If  the  dictionary  is  updated 
along  with  program  modifications,  it  becomes  consistent, 
reliable  documentation  that  is  essential  for  program 
maintenance. 

At  a  basic  level,  a  data  dictionary  is  composed  of  data 
elements  and  their  description.  This  reference  list  can  be 
used  to  evaluate   the  impact  of   proposed  changes,  prior   to 
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their  occurrence.     By  its   nature   it  provides   a   way   to 

highlight  standard  naming  conventions.  New  data  elements  to 

be   entered   in   the   dictionary   must  be   consistent   with 
existing  naming  conventions. 

C.   SYNOPSIS 

This  thesis  described  the  design,  implementation,  and 
use  of  a  basic  data  dictionary.  The  design  and  development 
of  an  undergraduate  transcript  summary  application  for  the 
Director  of  Admissions  at  NPS  was  used  to  evaluate  the 
benefits  of  the  data  dictionary.  The  concepts  of  dependent 
and  independent  dictionaries  were  discussed  and  the 
fundamental  principles  were  applied  to  the  dictionary 
design.  A  comparison  of  three  data  base  models  and  a 
summary  of  commercial  data  base  management  systems  and  data 
dictionaries  was  made.  The  advantages  and  disadvantages  in 
the  development  and  use  of  4BLs  were  discussed. 

As  the  scope  of  data  base  applications  in  an 
organisation  grows,  the  tendency  is  to  define  new  data 
elements  and  structures  rather  than  interpret  the  data  that 
already  exists.  The  data  dictionary  is  a  tool  that  provides 
programmers  with  access  to  standard  data  items  and 
structures.  It  is  the  responsibility  of  the  DBA  to  ensure 
that  these  standards  &re    maintained.   Management,  users,  and 
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data  processing   personnel  must   all   be  committed   to   this 
standardization  concept  before  any  benefits  can  be  realized. 
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APPENDIX    A 


DATA    DICTIONARY    SOURCE    CODE 


IS    THE    MAIN   MENU   FOR    THE    DATA   DICTIONARY 


ft*******#*****«#******t*tt##t*t ###**##**** **«****«****t***#t*#*t**ttt 

*  MODULE:  MAINMENU  FOCEXEC 

*  WRITTEN  BY:  BOB  REPP 

t  CALLED  BY:  PROJMENU  FOCEXEC 

*  CALLS:  MANTMENU.FILEMENU, EXECMENU  FOCEXEC 

*  PURPOSE:  MAIN  MENU  FOR  THE  DATA 

*  DICTIONARY 
» 

*♦*#****♦***«#****#♦*****♦♦♦♦♦******#*****♦♦**♦♦♦*******»**♦+*#♦♦**** 
SET  MS6=0FF 

-CRTCLEAR 

-BEGIN 

-CRTCLEAR 

-TYPE  THIS 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE   I" 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 


'MfiTfTMENO" 


INFORMATION  ON  FOCUS  FILES  <F> 

INFORMATION  ON  FOCEXECS  <E> 

DICTIONARY  MAINTENANCE  <M> 

QUIT  <Q> 


-TYPE 
-TYPE 
-TYPE 
-PROMPT  &SELECT.  WHAT  IS  YOUR  CHOICE?. 

:,F  else  if  HftfEf  11  T-  §8T8  nm 

ELSE  IF  &SELECT  IS  'M*  GOTO  MAINT 
ELSE  IF  &SELECT  IS  'Q'  60T0  EXIT 
ELSE  GOTO  BEGIN; 

-FILEMENU 

EXEC  FILEMENU 

-RUN 

-CRTCLEAR 

-60T0  BEGIN 

-EXECMENU 

EXEC  EXECMENU 

-RUN 

-CRTCLEAR 

-GOTO  BEGIN 

-MAINT 

EXEC  MANTMENU 

-RUN 

-CRTCLEAR 

-GOTO  BEGIN 

-EXIT 
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********************************************************************** 

*  MODULE:  HANTMENU  FOCEXEC  * 

*  WRITTEN  BY:  BOB  REPP  * 

*  CALLED  BY:  HAINHENU  FOCEXEC  * 

*  CALLS:  MODIFILE  FOCEXEC,  MODIEXEC  FOCEXEC     ♦ 

*  PURPOSE:  DICTIONARY  MAINTENANCE  MENU  * 

*  * 

*  * 
********************************************************************** 
-CRTCLEAR 

-FIRST  , 

-TYPE  THIS  IS  THE  MAINTENANCE  MENU  FOR  THE  DATA  DICTIONARY 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 
-TYPE 

-PROMPT  &WHICH.  WHAT  IS  YOUR  CHOICE?. 
-IF        ((WHICH  EQ  1  60T0  MODIFILE 

60T0  MODIEXEC 


MBTR'RERO" " 

--RATRTERBRCE'MERO' 


MODIFY  FILE  DATA  <1> 

MODIFY  EXEC  DATA  <2> 

EXIT  (to  main  tenu)  <X> 


ELSE  IF  ScWHICH  EQ 
ELSE  IF  &WHICH  IS 
ELSE  60T0  FIRSTj 

-MODIFILE 

EXEC  MODIFILE 

-RUN 

-CRTCLEAR 

-GOTO  FIRST 

-MODIEXEC 

EXEC  MODIEXEC 

-RUN 

-CRTCLEAR 

-60T0  FIRST 

-EXIT 

EOF: 


'X'  SOTO  EXIT 
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flBIfTRENO 

■~~EXEC"HATRTENRNCE"RERO" 


ADD  EXEC  INFORMATION  <1> 

UPDATE  EXEC  INFORMATION  ...  <2> 

DELETE  EXEC  INFORMATION  ...  <3> 

EXIT  (to  nam  menu)  <X> 


********************************************************************* 

*  MODULE:  MODIEXEC  FOCEXEC 

*  WRITTEN  BY:  BOB  REPP 

*  CALLED  BY:  MANTMENU  FOCEXEC 

*  CALLS:  ADDEXEC,  CH6EXEC.  DELEXEC  FOCEXEC 

*  PURPOSE:  EXEC  MAINTENANCE  MENU 
* 

* 

********************************************************************* 

-CRTCLEAR 

-PRIME 

-TYPE  THIS  IS  THE  EXEC  MAINTENANCE  MENU  FOR  THE  DATA  DICTIONARY 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-PROMPT  fcNHAT.  WHAT  IS  YOUR  ANSWER?. 

-IF        fcWHAT  EQ   1   GOTO  ADDEXEC 

-  ELSE  IF  fcWHAT  EQ   2   BOTO  CH6EXEC 

-  ELSE  IF  JtWHAT  EQ   3   60T0  DELEXEC 

-  ELSE  IF  &WHAT  IS   X'  60T0  EXIT 

-  ELSE  BOTO  PRIME} 
-ADDEXEC 
EXEC  ADDEXEC 
-RUN 

-CRTCLEAR 
-60T0  PRIME 
-CH6EXEC 
EXEC  CH6EXEC 
-RUN 

-CRTCLEAR 
-SOTO  PRIME 
-DELEXEC 
EXEC  DELEXEC 
-RUN 

-CRTCLEAR 
-60T0  PRIME 
-EXIT 


******************************************************************** 

MODULE:  ADDEXEC  FOCEXEC 

WRITTEN  BY:  BOB  REPP 

CALLED  BY:  MODIEXEC  FOCEXEC 

CALLS:  ADD1EXEC,ADD2EXEC,ADD3EXEC,ADD4EXEC 

PURPOSE:  ADD  MENU  UNDER  DICTIONARY  MAINTENANCE 

»*##*****«#***#*«*«##**«##«****** #«***#*«t**t*«*t«*t««* *#***##****«* 

FIRST 

CRTCLEAR 

TYPE  THIS  IS  THE  ADD  MENU  UNDER  DICTIONARY  MAINTENANCE 

TYPE 

TYPE 

TYPE 
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■RfilfTREflO" ■ 

"-RAIRTERfiRCE~RERO' 


■fiDD'EXECTRFORRATrOR" 


-TYPE 

-TYPE  I  "RfilR'RERO T 

-TYPE  I 

-TYPE  I 

-TYPE  I 

-TYPE  I 

-TYPE  I 

-TYPE  I 

-TYPE  ! 

-TYPE  I 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-PROMPT  iCHOQSE.  WHAT  IS  YOUR  CHOICE?. 

-IF         (CHOOSE  EQ  1  60T0  AOD1EXEC 


ADD  NEW  EXECS  

ADD  VARIABLES  TO  EXISTING  EXEC  

ADD  MASTER  FILES  USED  BY  AN  EXISTIN6  EXEC 

ADD  EXECS  CALLED  BY  AN  EXISTING  EXEC  

EXIT 


•>• 


<1> 
<2> 
<3> 
<4> 
<X> 


60T0  ADD2EXEC 
GOTO  ADD3EXEC 
60T0  ADD4EXEC 


ELSE  IF  &CHOOSE  EQ  2 

ELSE  IF  &CHOOSE  EQ  3 

ELSE  IF  &CHOOSE  EQ  4 

ELSE  IF  &CHOOSE  IS  'X'  GOTO  EXIT 

ELSE  60T0  FIRST; 
-ADD1EXEC 
;XEC  ADD1EXEC 
•RUN 

•CRTCLEAR 
-GOTO  FIRST 
■ADD2EXEC 
[XEC  ADD2EXEC 
■RUN 

■CRTCLEAR 
GOTO  FIRST 
-ADD3EXEC 
[XEC  ADD3EXEC 
-RUN 

-CRTCLEAR 
•60T0  FIRST 
-ADD4EXEC 
IXEC  ADD4EXEC 
•RUN 

•CRTCLEAR 
GOTO  FIRST 
■EXIT 


*  MODULE:  ADD1EXEC  FOCEXEC  * 

*  WRITTEN  BY:  BOB  REPP  * 

*  CALLED  BY:  ADDEXEC  FOCEXEC  § 

*  CALLS:  EDICTION  FOCUS.  EDICTION  MASTER        * 

*  PURPOSE:  ADD  NEW  EXECS  TO  DATABASE  * 

*  * 

*  ♦ 
************************************************  ********************** 
-CRTCLEAR 

MODIFY  FILE  EDICTION 
PROMPT  EXEC  NAME 
MATCH  EXEC  RAME 

ON  MATCH  REJECT 
ON  NOMATCH  PROMPT  PURPOSE 
NOMATCH  INCLUDE 
DATA 
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******************************************************************** 

MODULE:  ADD2EXEC  FOCEXEC 
WRITTEN  BY:  BOB  REPP 
CALLED  BY:  ADDEXEC  FOCEXEC 
CALLS:  EDICTION  FOCUS,  EDICTION  MASTER 
PURPOSE:  ADD  VARIABLES  TO  THE  DATA 
DICTIONARY  FOR  EXECS  ALREADY  IN  THE 
DICTIONARY 
»tt*»**f ft *## t#t # ************************ tt ***#*****#*## t#t ***♦♦**** 
-CRTCLEAR 

MODIFY  FILE  EDICTION 
PROMPT  EXEC  NAME  VAR  NAME 
MATCH  EXEC  RAME 

ON  MATCH  CONTINUE 
ON  NOMATCH  REJECT 
MATCH  VAR  NAME 

ON  MATCH  REJECT 

ON  NOMATCH  PROMPT  VAR  FORMAT  VAR  DESCRIPT 
ON  NOMATCH  INCLUDE 
DATA 

******************************************************************** 

MODULE:  ADD3EXEC  FOCEXEC 
WRITTEN  BY:  BOB  REPP 
CALLED  BY:  ADDEXEC  FOCEXEC 
CALLS:  EDICTION  FOCUS.  EDICTION  MASTER 
PURPOSE:  ADD  MASTER  FILES.  USED  BY  AN 
EXEC,  TO  THE  DATA  DICTIONARY 

******************************************************************** 

-CRTCLEAR 

MODIFY  FILE  EDICTION 
PROMPT  EXEC  NAME  FILE  NAME 
MATCH  EXEC  RAME 

ON  MATCH  CONTINUE 

ON  NOMATCH  REJECT 
MATCH  FILE  NAME 

ON  MATCH  REJECT 

ON  NOMATCH  INCLUDE 
DATA 

♦*******♦**♦*♦♦♦***♦****♦***«#**********♦*****♦**♦***************#** 

MODULE:  ADD4EXEC  FOCEXEC 

WRITTEN  BY:  BOB  REPP 

CALLED  BY:  ADDEXEC  FOCEXEC 

CALLS:  EDICTION  FOCUS,  EDICTION  MASTER 

PURPOSE:    ADD  EXECS  TO  THE  DATA 

DICTIONARY  THAT  ARE  CALLED  BY  AN  EXEC 
ALREADY  IN  THE  DICTIONARY 
«*##*******#**«*******###*#*****#** *t*tt**#**«*#**t**ttt**t********* 
-CRTCLEAR 

MODIFY  FILE  EDICTION 
PROMPT  EXEC  NAME  CALLED  EXEC 
MATCH  EXEC  RAME 

ON  MATCH  CONTINUE 
ON  NOMATCH  REJECT 
MATCH  CALLED  EXEC 

ON  MATCH"  REJECT 
ON  NOMATCH  INCLUDE 
DATA 
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RATR"*RERO T_. 

"RAIRTERARCE'RERO 

"OPDfiTE"EXEC"IRFORRATIOR" 


******************************************************************** 

MODULE:  CH6EXEC  FOCEXEC 
WRITTEN  BYl  BOB  REPP 
CALLED  BY:  MODIEXEC  FOCEXEC 
CALLS:  CH61EXEC,  CH62EXEC  FOCEXEC 
PURPOSE:  UPDATE  EXEC  MENU  UNDER 
DICTIONARY  MAINTENANCE 

******************************************************************** 

-MENU 

-CRTCLEAR 

-TYPEO  THIS  IS  THE  UPDATE  MENU  UNDER  DICTIONARY  MAINTENANCE 

-TYPE  } 

-TYPE 

-TYPE 

-TYPE 

-TYPE  ! 

-TYPE  ! 

-TYPE  ! 

-TYPE  I 

-TYPE  I 

-TYPE  I 

-TYPE  I 

-TYPE  i 

-TYPE  ! 

-TYPE 

-TYPE    I 

-TYPE 

-TYPE 

-PROMPT  «,CHOrCE7"BflfiT"TS"700R"CflOrCE?: 

-IF         &CHOICE  EQ  1  60T0  CH61EXEC 

ELSE  IF  ^CHOICE  EQ  2  60T0  CH62EXEC 

ELSE  IF  J.CHOICE  IS  'X'  SOTO  EXIT 

ELSE  60T0  MENU; 
-CH61EXEC 
EXEC  CH61EXEC 
-RUN 

-CRTCLEAR 
-SOTO  MENU 
-CHB2EXEC 
EXEC  CH62EXEC 
-RUN 

-CRTCLEAR 
-60T0  MENU 
-EXIT 


UPDATE  VARIABLE  FORMAT  OR  DESCRIPTION  <1> 

UPDATE  EXEC  PURPOSE  <2> 

EXIT  <X> 


ft********************************************************************* 

MODULE:  CH61EXEC  FOCEXEC  * 

WRITTEN  BY:  BOB  REPP  * 

CALLED  BY:  CH6EXEC  FOCEXEC  * 

CALLS:  EDICTION  FOCUS,  EDICTION  MASTER  * 

PURPOSE:  UPDATES  VARIABLE  INFORMATION  * 

IN  THE  DATA  DICTIONARY  * 

********************************************************************* 

-CRTCLEAR 

MODIFY  FILE  EDICTION 
PROMPT  EXEC  NAME  VAR  NAME 
MATCH  EXEC  RAME 

ON  NORATCH  REJECT 

ON  MATCH  CONTINUE 
MATCH  VAR  NAME 

ON  MATCH  PROMPT  VAR  FORMAT  VAR  DESCRIPT 

ON  MATCH  UPDATE  VAR"FORMAT  VAR'DESCRIPT 

ON  NOMATCH  REJECT   " 
DATA 
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******************************************************************** 

MODULE:  CH62EXEC  FOCEXEC 
WRITTEN  BYi  BOB  REPP 
CALLED  BYi    CH6EXEC  FOCEXEC 
CALLS:    EDICT  ION  FOCUS,  EDICTION  MASTER 
PURPOSE:  UPDATES  EXEC  PURPOSE  IN  THE 
DATA  DICTIONARY 

******************************************************************** 

-CRTCLEAR 

MODIFY  FILE  EDICTION 
PROMPT  EXEC  NAME  PURPOSE  , 
MATCH  EXEC  NAME 

ON  NOflATCH  REJECT 

ON  MATCH  UPDATE  PURPOSE 
DATA 


******************************************************************** 

MODULE:  DELEXEC  FOCEXEC 
WRITTEN  BY:  BOB  REPP 
CALLED  BY:  MODIEXEC  FOCEXEC 
CALLS:  DEL1EXEC,DEL2EXEC,DEL3EXEC,DEL4EXEC 
PURPOSE:  EXEC  DELETE  MENU  UNDER 
DICTIONARY  MAINTENANCE 

******************************************************************** 

-FIRST 
■CRTCLEAR 

■TYPE  THIS  IS  THE  DELETE  MENU  UNDER  DICTIONARY  MAINTENANCE 
■TYPE 
■TYPE 
•TYPE 
■TYPE 
■TYPE 
•TYPE 
■TYPE 
•TYPE 
•TYPE 
•TYPE 
-TYPE 
TYPE 
•TYPE 
■TYPE 
■TYPE 

■TYPE  : 

■TYPE  I 

•PROMPT   &WHrCfl:"HflfiT"r5"700R"Cfl0rCE7; 


RBIFTNENO 

— HfilRTENARCE'RERO" 


DECETE"EXEC"lNFORRBTION- 


DELETE 
DELETE 
DELETE 
DELETE 
EXIT  . 


ALL  INFORMATION  ON  AN  EXEC  <1> 

INFO  ON  A  VARIABLE  USED  IN  AN  EXEC  ....  <2> 

INFO  ON  A  MASTER  FILE  USED  BY  AN  EXEC  .  <3> 

INFORMATION  ON  A  CALLED  EXEC  <4> 

<X> 


-IF 


ELSE 
ELSE 
ELSE 
ELSE 


&WHICH  EQ 
IF  &WHICH  EQ 
IF  &WHICH  EQ 
IF  &WHICH  EQ 
IF  &WHICH  IS 
ELSE  BOTO  FIRST; 

DEL1EXEC 

XEC  DEL1EXEC 

RUN 

CRTCLEAR 

60T0  FIRST 

DEL2EXEC 

XEC  DEL2EXEC 

RUN 

CRTCLEAR 

SOTO  FIRST 

DEL3EXEC 

XEC  DEL3EXEC 

RUN 

CRTCLEAR 

GOTO  FIRST 


1  SOTO  DEL1EXEC 

2  60T0  DEL2EXEC 

3  GOTO  DEL3EXEC 

4  60T0  DEL4EXEC 
X  GOTO  EXIT 
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-DEL4EXEC 
EXEC  DEL4EXEC 
-RUN 

-CRTCLEAR 
-6QT0  FIRST 
-EXIT 

ft*****************************!*************************************** 

*  MODULE:  DEL1EXEC  FOCEXEC  * 

*  WRITTEN  BY:  BOB  REPP  * 

*  CALLED  BY:  DELEXEC  FOCEXEC  * 
t                     CALLS:  EDICTION  FOCUS,  EDICTION  MASTER        * 

*  PURPOSE:  DELETE  ALL  INFORMATION  IN  THE        * 

*  DATA  DICTIONARY  ON  AN  EXEC  * 

*  * 
**#t**o*t*«**********#*******##******#«##  *****#  ft********************* 
-CRTCLEAR 

MODIFY  FILE  EDICTION 
PROMPT  EXEC  NAME 
MATCH  EXEC  NAME 

ON  MATCH  DELETE 

ON  NOMATCH  REJECT 
DATA 

*  MODULE:  DEL2EXEC  FOCEXEC  * 

*  WRITTEN  BY:  BOB  REPP  * 

*  CALLED  BY:  DELEXEC  FOCEXEC  * 

*  CALLS:  EDICTION  FOCUS,  EDICTION  MASTER  * 

*  PURPOSE:  DELETE  ALL  INFORMATION  IN  THE  * 

*  DATA  DICTIONARY  ON  A  VARIABLE  USED  * 

*  IN  AN  EXEC  * 
##***********#****#**#**#♦*#***********#*♦***#*******#**#***♦***♦#*♦#» 
-CRTCLEAR 

MODIFY  FILE  EDICTION 
PROMPT  EXEC  NAME  VAR  NAME 
MATCH  EXEC  RAME 

ON  MATCH  CONTINUE 

ON  NOMATCH  REJECT 
MATCH  VAR  NAME 

ON  MfiTCH  DELETE 

ON  NOMATCH  REJECT 
DATA 

*  MODULE:  DEL3EXEC  FOCEXEC  * 

*  WRITTEN  BY:  BOB  REPP  « 

*  CALLED  BY:  DELEXEC  FOCEXEC  * 

*  CALLS:  EDICTION  FOCUS,  EDICTION  MASTER  * 

*  PURPOSE:  DELETE  INFORMATION  IN  THE  * 

*  DICTIONARY  ON  MASTER  FILES  CALLED  * 

*  BY  AN  EXEC  * 
********************************************************************** 
-CRTCLEAR 

MODIFY  FILE  EDICTION 
PROMPT  EXEC  NAME  FILE  NAME 
MATCH  EXEC  RAME 

ON  MATCH  CONTINUE 

ON  NOMATCH  REJECT 
MATCH  FILE  NAME 

ON  MATCH  DELETE 

ON  NOMATCH  REJECT 
DATA 
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44444444444444444444444444444444444444444444444444444444444444444444 

MODULES  DEL4EXEC  FOCEXEC 

WRITTEN  BY:  BOB  REPP 

CALLED  BY:  DELEXEC  FOCEXEC 

CALLS:  EDICTION  FOCUS.  EDICTION  MASTER 

PURPOSE:  DELETE  INFORMATION  IN  THE 

DICTIONARY  ON  AN  EXEC  CALLED  BY  AN  EXEC 

44444444444444444444444444444444444444444444444444444444444444444444 

-CRTCLEAR 

MODIFY  FILE  EDICTION 

PROMPT  EXEC  NAME  CALLED  EXEC 

MATCH  EXEC  RAME 

ON  MATCH  CONTINUE 

ON  NOMATCH  REJECT 
MATCH  CALLED  EXEC 

ON  MATCH  DELETE 

ON  NOMATCH  REJECT 
DATA 


44444444444444444444444444444444444444444444444444444444444444444444 

MODULE:  MODIFILE  FOCEXEC 

WRITTEN  BY:  BOB  REPP 

CALLED  BY:     MANTMENU  FOCEXEC 

CALLS:  ADDFILE.  CH6FILE.  DELFILE  FOCEXEC 

PURPOSE:  MASTER  FILE  MAINTENANCE  MENU 

44444444444444444444444444444444444444444444444444444444444444444444 

CRTCLEAR 

PRIME 

TYPE  THIS  IS  THE  FILE  MAINTENANCE  MENU  FOR  THE  DATA  DICTIONARY 

TYPE 

TYPE 

TYPE 

TYPE 

TYPE 

TYPE 

TYPE 

TYPE 

TYPE 

TYPE 

TYPE 

TYPE 

TYPE 

TYPE 

TYPE 

TYPE 

TYPE 

TYPE 

PROMPT  fcWHAT.  WHAT 

IF        &WHAT  IS 

ELSE  IF  &WHAT  IS 

ELSE  IF  &WHAT  IS 

ELSE  IF  &WHAT  IS 


"MAIN'RENO 

■"FKE-MAINTENBNCE"MENU' 


ADD  FILE  INFORMATION  .., 
UPDATE  FILE  INFORMATION 
DELETE  FILE  INFORMATION 


<1> 
<2> 
<3> 


EXIT  (to  main  menu)  <X> 


IS 
1 
2 
3 

'X 


YOUR  ANSWER?. 
GOTO  ADDFILE 
60T0  CH6FILE 
SOTO  DELFILE 
GOTO  EXIT 


■   ELSE  SOTO 
■ADDFILE 
[XEC  ADDFILE 
•RUN 

■CRTCLEAR 
■60T0  PRIME 
■CH6FILE 
iXEC  CH6FILE 
•RUN 

■CRTCLEAR 
•60T0  PRIME 
•DELFILE 
[XEC  DELFILE 


PRIME; 
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-RUN 

-CRTCLEAR 
-60T0  PRIME 
-EXIT 


ft******************* **********#**«*«*«**********##**##***#******ttt#t* 

*                    MODULE!  ADDFILE  FOCEXEC                     * 

*                     WRITTEN  BY:  BOB  REPP                        * 

*                     CALLED  BY:  MODIFILE  FOCEXEC                  * 

*  CALLS:  ADD1FILE,ADD2FILE,ADD3FILE            * 

*  PURPOSE:  ADD  MENU  UNDER  DICTIONARY  MAINTENANCE* 

«                      f                                                                                                    * 

*                                                                                                                                                          * 

-CRTCLEAR 

-TYPE  THIS  IS  THE  ADD  MENU  UNDER  DICTIONARY  MAINTENANCE 

-FIRST 

-TYPE 

-TYPE 

-TYPE 

-TYPE 
-TYPE  1"  "1 

*AIR~RERD              ! 

-TYPE 

- 1 

i 

-TYPE 

1"' 

■~FICE-flAlNTERARCE"HENO i 

-TYPE 

—  i 
i 

-TYPE 

""'ADD"FTCE"TRFORflATIOR 

-TYPE 

-TYPE 

ADD  NEW  MASTER  FILES <1> 

-TYPE 

ADD  SEGMENTS  TO  A  MASTER  FILE <2> 

-TYPE  1  1 

ADD  FIELDS  TO  A  SEGMENT <3> 

-TYPE   ~! 

EXIT  <X> 

-TYPE    ! 

-TYPE 

-TYPE 
-TYPE 

-PROMPT  &CHQOSE.  WHAT  IS  YOUR  CHOICE?. 

-IF         &CHOOSE  EQ  1  GOTO  ADD1FILE 

ELSE  IF  ttCHOOSE  EQ  2  SOTO  ADD2FILE 

ELSE  IF  iCHOOSE  EQ  3  GOTO  ADD3FILE 

ELSE  IF  IcCHOOSE  IS  'X'  GOTO  EXIT 

ELSE  GOTO  FIRST; 

-ADD1FILE 

EXEC  ADD1FILE 

-RUN 

-CRTCLEAR 

-GOTO  FIRST 

-ADD2FILE 

EXEC  ADD2FILE 

-RUN 

-CRTCLEAR 

-GOTO  FIRST 

-ADD3FILE 

EXEC  ADD3FILE 

-RUN 

-CRTCLEAR 

-GOTO  FIRST 

-EXIT 

********************************************************************** 

*  MODULE:  ADD1FILE  FOCEXEC  * 

*  WRITTEN  BY:  BOB  REPP  * 

*  CALLED  BY:  ADDFILE  FOCEXEC  * 

*  CALLS:  FDICTION  FOCUS  ,  FDICTION  MASTER  * 

*  PURPOSE:  ADD  NEW  MASTER  FILES  TO  DATABASE  * 

*  DICTIONARY  * 

*  * 
♦♦ft****************************************************************** 
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-CRTCLEAR 

MODIFY  FILE  FDICTION 
PROMPT  FILE  NAME 
MATCH  FILE  NAME 

ON  MATCH  REJECT 

ON  NOMATCH  PROMPT  FILE  TYPE  NUM  SE6S 

ON  NOMATCH  PROMPT  FILE'DESCRIP  MAINTAIN  BY 

ON  NOMATCH  INCLUDE 
DATA 

******************************************************************** 

NODULE:  ADD2FILE  FOCEXEC 
WRITTEN  BY:  BOB  REPP 
CALLED  BY:  ADDFILE  FOCEXEC 
CALLS:  FDICTION  FOCUS,  FDICTION  MASTER 
PURPOSE:  ADD  SE6MENTS  TO  THE  DICTIONARY 
FOR  MASTER  FILES  IN  THE  DICTIONARY 

********************************************  *************  *********** 

-CRTCLEAR 

MODIFY  FILE  FDICTION 
PROMPT  FILE  NAME  SE6  NAME 
MATCH  FILE  RAME 

ON  MATCH  CONTINUE 

ON  NOMATCH  REJECT 
MATCH  SE6  NAME 

ON  MATCH  REJECT 

ON  NOMATCH  PROMPT  CHILD  OF  SE6  TYPE  SE6  DESCRIPT 

ON  NOMATCH  INCLUDE 
DATA 

*«******♦*********«***#*****♦*#*#♦♦*♦**♦**************♦*♦♦♦**♦**«♦♦♦* 

*  MODULE:  ADD3FILE  FOCEXEC 

*  WRITTEN  BY:  BOB  REPP 

*  CALLED  BY:  ADDFILE  FOCEXEC 

*  CALLS:  FDICTION  FOCUS,  FDICTION  MASTER 
t  PURPOSE:  ADDS  FIELDS  TO  THE  DATA 

*  DICTIONARY  FOR  SE6MENTS  IN  THE 

*  DICTIONARY 

**********♦#*♦****♦»*♦************♦♦****♦***♦***♦*♦**♦*•***#********* 
-CRTCLEAR 

MODIFY  FILE  FDICTION 

PROMPT  FILE  NAME  SE6  NAME  FIELD  NAME 

MATCH  FILE  RAME 

ON  MATCH  CONTINUE 

ON  NOMATCH  REJECT 
MATCH  SE6  NAME 

ON  MATCH  CONTINUE 

ON  NOMATCH  REJECT 
MATCH  FIELD  NAME 

ON  MATCH  REJECT 

ON  NOMATCH  PROMPT  ALTERNATE  FIELD  FORMAT  FIELD  TYPE 

ON  NOMATCH  PROMPT  KEY  FIELD  DESCRl 

ON  NOMATCH  INCLUDE 
DATA 

««##***«t*#«##t#«t*«t#***ft**«***#*#««*t****#*#*t**#******t#t*ttt#*t#* 

MODULE:  DELFILE  FOCEXEC  t 

WRITTEN  BY:  BOB  REPP  * 

CALLED  BY:  MODIFILE  FOCEXEC  * 

CALLS:  DEL1FILE,DEL2FILE,DEL3FILE  FOCEXEC     t 
7[C     P7RC0SE:      DELETE  FILE  MENU  UNDER  * 

DICTIONARY  MAINTENANCE  * 

* 

FIRST 

108 


-CRTCLEAR 

-TYPE  THIS  IS  THE  DELETE  HENU  UNDER  DICTIONARY  MAINTENANCE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE  I 

-TYPE  I 

-TYPE  ! 

-TYPE  I 

-TYPE  ! 

-TYPE  I 

-TYPE  ! 

-TYPE  I 

-TYPE  ! 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-PROMPT  &NHICH. 


■flATR-RENO ! . 

■"FKE'RATNTENANCE'flENO""' 

r~"ADD~FTCE~lNFORHATION"" 

DELETE  'ALL  INFO  ON 
DELETE  ALL  INFO  ON 
DELETE  ALL  INFO  ON 
EXIT  


MASTER  FILE 

SE6MENT  

FIELD , 


<1> 
<2> 
<3> 
<X> 


WHAT  IS  YOUR  CHOICE?. 


-IF 


((WHICH  EQ 
ELSE  IF  &WHICH  EQ 
ELSE  IF  &WHICH  EQ 
ELSE  IF  fcWHICH  IS 
ELSE  60T0  FIRST} 

DEL1FILE 

XEC  DELiFILE 

RUN 

CRTCLEAR 

GOTO  FIRST 

DEL2FILE 

XEC  DEL2FILE 

RUN 

CRTCLEAR 

SOTO  FIRST 

DEL3FILE 

XEC  DEL3FILE 

RUN 

CRTCLEAR 

60T0  FIRST 

EXIT 


1  SOTO  DELIFILE 

2  60T0  DEL2FILE 

3  SOTO  DEL3FILE 
X  60T0  EXIT 


ft********************************************************************* 

*  MODULE:  DELIFILE  FOCEXEC  * 

*  WRITTEN  BY:  BOB  REPP  « 

*  CALLED  BY:  DELFILE  FOCEXEC  * 

*  CALLS:  FDICTION  FOCUS,  FDICTION  MASTER        ♦ 

*  PURPOSE:  DELETE  ALL  INFORMATION  IN  THE        * 

*  DATA  DICTIONARY  ON  A  MASTER  FILE  * 
t  * 
******  t«*«*«***o*t**o«*#*#*#**t«#t  *«##«#**«**#*«**«#*«#*«****#*****« 
-CRTCLEAR 

MODIFY  FILE  FDICTION 
PROMPT  FILE  NAME 
MATCH  FILE  RAME 

ON  MATCH  DELETE 

ON  NOMATCH  REJECT 
DATA 
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******************************************************************** 

MODULEt  DEL2FILE  FOCEXEC 

WRITTEN  BY:  BOB  REPP 

CALLED  BY:  DELFILE  FOCEXEC 

CALLSi  FDICTION  FOCUS.  FDICTION  MASTER 

PURPOSE:  DELETE  INFORMATION  IN  THE  DATA 

DICTIONARY  ON  A  SE6MENT  OF  A  MASTER 

FILE 
******************************************************************** 

-CRTCLEAR 

MODIFY  FILE  FDICTION 
PROMPT  FILE  NAME  SE6  NAME 
MATCH  FILE  NAME 

ON  MATCH  CONTINUE 

ON  NOMATCH  REJECT 
MATCH  SE6  NAME 

ON  NOMATCH  REJECT 

ON  MATCH  DELETE 
DATA 

#♦♦***********#*****♦*******♦****♦#*♦♦**♦*****»**♦*****♦****** *»t**t 

MODULEi  DEL3FILE  FOCEXEC 
WRITTEN  BY:  BOB  REPP 
CALLED  BY:  DELFILE  FOCEXEC 
CALLS:  FDICTION  FOCUS,  FDICTION  MASTER 
PURPOSE:  DELETE  INFORMATION  IN  THE  DATA 
DICTIONARY  ON  ONE  FIELD  IN  A  SE6MENT 
OF  A  MASTER  FILE 
***********♦*****#*«***♦**********♦******#**#*****♦*****»****#****** 

-CRTCLEAR 

MODIFY  FILE  FDICTION 

PROMPT  FILE  NAME  SE6  NAME  FIELD  NAME 

MATCH  FILE  RAME 

ON  NOMATCH  REJECT 

ON  MATCH  CONTINUE 
MATCH  SEG  NAME 

ON  NOMATCH  REJECT 

ON  MATCH  CONTINUE 
MATCH  FIELD  NAME 

ON  NQMfiTCH  REJECT 

ON  MATCH  DELETE 
DATA 

»***#***###******««## *#*tt*t**t**t*t#**ttt#t*#*t#tt**##tt#**#*t**tt* 

MODULE:    CH6FILE  FOCEXEC 
WRITTEN  BY:  BOB  REPP 
CALLED  BY:  MODIFILE  FOCEXEC 
CALLS:  CH61FILE,CH62FILE,CH63FILE 
PURPOSE:  UPDATE  FILE  MENU  UNDER 
DICTIONARY  MAINTENANCE 

******************************************************************** 

-SECOND 

-CRTCLEAR 

-TYPE  THIS  IS  THE  UPDATE  MENU  UNDER  DICTIONARY  MAINTENANCE 

-TYPE 
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RATR'RERO" 


FTCE'RAIRTERARCE'RERO" 


OPDATE~FICE"IRFORRATIOR' 


UPDATE  MASTER  FILE  INFORMATION 
UPDATE  SE6MENT  INFORMATION  .... 

UPDATE  FIELD  INFORMATION 

EXIT...' 


-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE    I  ! 

-TYPE    "I 

-TYPE     I         

-TYPE 

-PROMPT  ((CHOICE.  WHAT  IS  YOUR  CHOICE?. 

-IF         ((CHOICE  EQ  1  60T0  CH61FILE 

ELSE  IF  ((CHOICE  EQ 

ELSE  IF  ((CHOICE  EQ 

ELSE  IF  ((CHOICE  IS 

ELSE  GOTO  SECOND; 
-CH81FILE 
EXEC  CHGIFILE 
-RUN 

-CRTCLEAR 
-60T0  SECOND 
-CHB2FILE 
EXEC  CH62FILE 
-RUN 

-CRTCLEAR 
-60T0  SECOND 
-CH63FILE 
EXEC  CH63FILE 
-RUN 

-CRTCLEAR 
-60T0  SECOND 
-EXIT 


<i> 
<2> 
<3> 
<X> 


60T0  CH62FILE 
60T0  CH63FILE 


'X'  60T0  EXIT 


********************** 

* 

* 

* 

* 

* 

* 

* 

********************** 

-CRTCLEAR 

MODIFY  FILE  FDICTION 

PROMPT  FILE  NAME 

MATCH  FILE  RAME 

ON  NORATCH  REJECT 
ON  MATCH  PROMPT  F 
ON  MATCH  UPDATE  F 

DATA 


************************************************ 

MODULE:    CHG1FILE  FOCEXEC  * 

WRITTEN  BY:  BOB  REPP  * 

CALLED  BY:  CH6FILE  FOCEXEC  * 

CALLS:  FDICTION  FOCUS,  FDICTION  MASTER        * 
PURPOSE:  UPDATES  MASTER  FILE  INFORMATION      * 
IN  THE  DATA  DICTIONARY  * 

* 
************************************************ 


ILE  NAME  NUM  SE6S  FILE  DESCRIP  MAINTAIN  BY 
ILE'TYPE  NUM"SE6S  FILE'DESCRIP  MAINTAIN'BY 


********************************************************************** 

*  MODULE:  CHB2FILE  FOCEXEC  * 

*  WRITTEN  BY:  BOB  REPP  * 

*  CALLED  BY:  CH6FILE  FOCEXEC  * 

*  CALLS:  FDICTION  FOCUS,  FDICTION  MASTER        * 

*  PURPOSE:  UPDATES  SEGMENT  INFORMATION  * 

*  IN  THE  DATA  DICTIONARY  * 

*  « 
********************************************************************** 
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-CRTCLEAR 

MODIFY  FILE  FDICTION 
PROMPT  FILE  NAME  SE8  NAME 
MATCH  FILE  flAME 

ON  MATCH  CONTINUE 

ON  NOMATCH  REJECT 
MATCH  SE6  NAME 

ON  NOMATCH  REJECT 

ON  MATCH  PROMPT  CHILD  OF  SE6  TYPE  SE6  DESCRIPT 

ON  MATCH  UPDATE  CHILD'OF  SE6"TYPE  SE6"DESCRIPT 
DATA  " 

ft*t#****«*********ft**t***«#*#«t******t**t**t*#*****##t**********#*t* 

MODULE:  CHS3FILE  FOCEXEC 
WRITTEN  BY:  BOB  REPP 
CALLED  BY:  CH6FILE  FOCEXEC 
CALLS:  FDICTION  FOCUS,  FDICTION  MASTER 
PURPOSE:  UPDATES  FIELD  INFORMATION 
IN  THE  DATA  DICTIONARY 

**ftft**«*##**#*ftftt*tt*t*****tt*«**ft*#*********#**ftt*ft*tt#ft**t*ft*ftftt*t*< 

-CRTCLEAR 

MODIFY  FILE  FDICTION 

PROMPT  FILE  NAME  SE6  NAME  FIELD  NAME 

MATCH  FILE  RAME 

ON  NOMATCH  REJECT 

ON  MATCH  CONTINUE 
MATCH  SES  NAME 

ON  NOMATCH  REJECT 

ON  MATCH  CONTINUE 
MATCH  FIELD  NAME 

ON  NOMflTCH  REJECT 

ON  MATCH  PROMPT  ALTERNATE  FIELD  FORMAT  FIELD  TYPE  KEY  FIELD  DESCRI 

ON  MATCH  UPDATE  ALTERNATE  FIELD'FORMAT  FIELD"TYPE  KEY  FIELD"DESCRI 
DATA 
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EXEC  DESCRIPTIONS  <1> 

VARIABLE  INFORMATION  <2> 

SUMMARY  REPORT <3> 

EXIT  (return  to  aain  menu).  <X> 


********************************************************************** 

*  MODULE:  EXECMENU  FOCEXEC  * 
«                     WRITTEN  BY:  BOB  REPP  * 

*  CALLED  BY:  MAINMENU  FOCEXEC  * 

*  CALLS:  EXECDESC.EXECINFO.SUMEXEC  FOCEXEC      * 

*  PURPOSE:  MENU  FOR  "CANNED"  DICTIONARY         * 

*  REPORTS  * 

*  * 
********************************************************************** 
-START 

-CRTCLEAR 

-TYPE  THIS  MENU  ALLOWS  THE  USER  TO  ACCESS  INFORMATION  ON  FOCUS  EXECS 

-TYPE  r' 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE   I"'"RAIN"RERD"""  I 

-TYPE 

-TYPE    I — EHEC'RENO" 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-PROMPT  &CHOICE.  WHAT  IS  YOUR  CHOICE?. 

-IF         JtCHOICE  EQ  1  SOTO  DESCRIPT 

ELSE  IF  &CHOICE  EQ  2  60T0  INFO 

ELSE  IF  JtCHOICE  EQ  3  SOTO  SUMMARY 

ELSE  IF  &CHOICE  IS  'X'  SOTO  EXIT 

ELSE  SOTO  START; 
-DESCRIPT 
EXEC  EXECDESC 
-RUN 

-60T0  START 
-INFO 

EXEC  EXECINFO 
-RUN 

-SOTO  START 
-SUMMARY 
EXEC  SUMEXEC 
-RUN 

-SOTO  START 
-EXIT 

ft********************************************************************* 

*  MODULE:  EXECINFO  FOCEXEC  * 

*  WRITTEN  BY:  BOB  REPP  * 

*  CALLED  BY:  EXECMENU  FOCEXEC  * 

*  CALLS:  EDICTION  FOCUS,  EDICTION  MASTER        * 

*  PURPOSE:  PRINTS  VARIABLE  INFORMATION  BY  EXEC   * 

*  FOR  EVERY  EXEC  IN  THE  DATA  DICTIONARY       * 

*  * 

**«##*t«**#«*«*04M**************************#*******#*******#*t****** 

-CRTCLEAR 

TABLE  FILE  EDICTION 

PRINT  VAR  NAME  VAR  FORMAT  VAR  DESCRIPT 

BY  EXEC  NAME 

FOOTINS'CENTER 

"TYPE  QUIT  TO  RETURN  TO  MENU" 

RUN 
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A******************************************************************** 

*  MODULE:  EXECDESC  FOCEXEC 

*  WRITTEN  BY:  BOB  REPP 

*  CALLED  BY:  EXECMENU  FOCEXEC 

*  CALLS:  EDICTION  FOCUS,  EDICTION  MASTER 

*  PURPOSE:  PRINTS  EXEC  NAME  AND  PURPOSE 

*  FOR  EVERY  EXEC  IN  THE  DATA  DICTIONARY 
* 

********************************************************************* 
-CRTCLEAR 

TABLE  FILE  EDICTION 

PRINT  EXEC  NAME  PURPOSE 

FOOTING  CENTER 

"TYPE  QUIT  TO  RETURN  TO  MENU" 

RUN 


I 


***** 

* 

« 

* 

* 

* 

* 

* 

* 

***** 

-CRTC 

JOIN 

TABLE 

PRINT 

BY  EX 

FOOTI 

"TYPE 

RUN 


**************************************************************** 

MODULE:  SUMEXEC  FOCEXEC 

WRITTEN  BY:  BOB  REPP 

CALLED  BY:  EXECMENU  FOCEXEC 

CALLS:  EDICTION  FOCUS,  EDICTION  MASTER 
FDICTION  FOCUS.  FDICTION  MASTER 

PURPOSE:  JOINS  FDICTION  AND  EDICTION  IN 
PRINT  CALLED  EXECS  AND  MASTER  FILES  USED 
EXEC  IN  THE  DATA  DICTIONARY 
************************************************* 


ORDER  TO 
BY  EVERY 
*************** 

LEAR 

FILE  NAME  IN  ED 
FILE  EDICTION 
CALLED  EXEC  FI 

EC  NAME" 

NB'CENTER 
QUIT  TO  RETURN 


ICTION  TO  FILE.NAME  IN  FDICTION  AS  JJOIN 
LE.NAME  FILE.DESCRIP 

TO  MENU" 


********************************************************************* 

*  MODULE:  FILEMENU  FOCEXEC 

*  WRITTEN  BY:  BOB  REPP 

*  CALLED  BY:  MAINMENU  FOCEXEC 

*  CALLS:  FILDESC.SE6INF0.FLDINF0  FOCEXEC 

*  PURPOSE:  MENU  OF  "CANNED"  REPORTS  FROM 

*  THE  DICTIONARY  ON  MASTER  FILES 
* 

ft******************************************************************** 
-START 

-CRTCLEAR 

-TYPE  THIS  MENU  ALLOWS  THE  USER  TO  ACCESS  INFORMATION  ON  FOCUS  FILES 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-PROMPT 

-IF 


■RAIN'HENU"" 
—  FKE-MERQ" 


FILE  DESCRIPTIONS  <1> 

SEGMENT  INFORMATION  <2> 

FIELDNAME  INFORMATION  <3> 

SUMMARY  REPORT  <4> 

EXIT  (return  to  nain  nenu).  <X> 


^CHOICE.  WHAT  IS 
fcCHOICE  EQ  1 


YOUR 
GOTO 


CHOICE?. 
DESCRIPT 


114 


ELSE  IF  ((CHOICE  EQ 
ELSE  IF  ((CHOICE  EQ 
ELSE  IF  ((CHOICE  EQ 
ELSE  IF  &CHOICE  IS 
ELSE  80T0  START} 

-DESCRIPT 

EXEC  FILDESC 

-RUN 

-CRTCLEAR 

-60T0  START 

-SINFO 

EXEC  SEGINFO 

-RUN 

-CRTCLEAR 

-60T0  START 

-FINFO 

EXEC  FLDINFO 

-RUN 

-CRTCLEAR 

-60T0  START 

-SUMMARY 

EXEC  SUMFILE 

-RUN 

-CRTCLEAR 

-60T0  START 

-EXIT 


2  60T0  SINFO 

3  GOTO  FINFO 

4  SOTO  SUMMARY 
'X'  SOTO  EXIT 


>  , 


#*#*****#*#*#o****o*#******#**********************#*********#*****«# 

*  MODULE:  FILDESC  FOCEXEC  * 

*  WRITTEN  BY:  BOB  REPP  * 

*  CALLED  BY:  FILEMENU  FOCEXEC  * 

*  CALLS:  FDICTION  FOCUS,  FDICTION  MASTER        * 

*  PURPOSE:  PRINTS  FILE  NAME,  DESCRIPTION.  ETC.   * 

*  ON  EVERY  MASTER  FILE  IN  THE  DICTIONARY      * 

*  * 
*******«***********ft******«*#****o***#****#***«*##*******#******#**** 
-CRTCLEAR 

TABLE  FILE  FDICTION 

PRINT  FILE  NAME  FILE  DESCRIP  MAINTAIN  BY  FILE  TYPE  NUM  SEGS 

FOOTING  CERTER      "  " 

"TYPE  QUIT  TO  RETURN  TO  MENU" 

RUN 


♦a******************************************************************** 

*  MODULE:  FLDINFO  FOCEXEC  * 

*  WRITTEN  BY:  BOB  REPP  * 

*  CALLED  BY:  FILEMENU  FOCEXEC  * 

*  CALLS:  FDICTION  FOCUS,  FDICTION  MASTER        * 

*  PURPOSE:  PRINTS  FIELD  NAME,  DESCRIPTION,      * 

*  AND  ALIAS  BY  MASTER  FILE  FOR  EVERY  * 

*  FIELD  IN  THE  DATA  DICTIONARY  * 
********************************************************************** 
-CRTCLEAR 

TABLE  FILE  FDICTION 

PRINT  FIELD  NAME  FIELD  DESCRI  ALTERNATE 

BY  FILE  NAME 

FOOTING'CENTER 

"TYPE  QUIT  TO  RETURN  TO  MENU" 

RUN 
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********************************************************************* 

*  MODULE:  SEBINFO  FOCEXEC 

*  WRITTEN  BY:  BOB  REPP 

*  CALLED  BY:  FILEMENU  FOCEXEC 

*  CALLS:  FDICTION  FOCUS,  FDICTION  MASTER 

*  PURPOSE:      PRINT  SEBMENT  NAME,  DESCRIPTION 

*  AND  PARENT  BY  MASTER  FILE  FOR  EVERY 

*  SEBMENT  IN  THE  DICTIONARY 
********************************************************************* 

-CRTCLEAR 

TABLE  FILE  FDICTION 

PRINT  SEE  NAME  SE6  DESCRI,PT  CHILD  OF  SE6  TYPE 

BY  FILE  NfiME      "  " 

F00TIN6"CENTER 

"TYPE  QUIT  TO  RETURN  TO  MENU" 

RUN 

********************************************************************* 

*  MODULE:  SUMFILE  FOCEXEC 

*  WRITTEN  BY:  BOB  REPP 

*  CALLED  BY:  FILEMENU  FOCEXEC 

*  CALLS:  FDICTION  FOCUS,  FDICTION  MASTER 

*  PURPOSE:  PRINTS  FILE,  SEBMENT,  AND  FIELD 

*  INFORMATION  FOR  EVERY  MASTER  FILE  IN 

*  THE  DATA  DICTIONARY 
********************************************************************* 

-CRTCLEAR 

TABLE  FILE  FDICTION 

PRINT  FIELD  NAME  ALTERNATE  KEY   FIELD  TYPE 

BY  FILE  NAME 

BY  SES  RAME 

FOOTIN6  CENTER 

"TYPE  QUIT  TO  RETURN  TO  MENU" 

RUN 
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SAMPLE  DICTIONARY  REPORTS 


FILE.NAME 

FILE.DESCRIP 

MAINTAIN.! 

BY 

FILE. 

TYPE 

NUM.SE6S 

FDICTION 

MASTER  FILE  DICTIONARY     DESI6NER 

FOC 

3 

EDICTION 

EXEC  MASTER  DICTIONARY     R.C.REPP 

FOC 

4 

ADMISSIO 

STUD  AND  COURSES  TAKEN     NAV  ACAD 

FOC 

2 

AVAIL 

CREDIT  HRS  BY 

COURSE       NAV  ACAD 

FOC 

1 

REQ 

COURSE  SUBJ  AREAS          NPS 

FOC 

1 

FILE.NAME 

SEG.NAME  SE6 

.DESCRIPT 

CHILD.OF 

SEG. 

TYPE 

ADMISSIO 

COURSE    STUD  GRADES  BY  COURSE 

STUDENT 

SI 

STUDENT   STUD  ID  AND  INFO 

SI 

AVAIL 

DESCRIPT   CREDIT  HRS  BY  COURSE 

ACOUR 

SI 

EDICTION 

CALLED    EXECS  CALLED  BY  AN  EXEC 

EXECS 

SI 

EXECS     FOCEXEC  DESCRIPTIONS 

EDICTION 

SI 

FILE  NAM   MASTER  FILES  USED 

EXECS 

SI 

VARIABLE   VARIABLE  INFORMATION 

EXECS 

SI 

FDICTION 

FIELDS    INFO  ON  SE6MENT  FIELDS 

SEGMENTS 

SI 

FILES     INFO  ON  MASTER  FILES 

FDICTION 

SI 

SE6MENTS   INFO  ON  MASTER  SEGMENTS 

FILES 

SI 

REQ 

DESCRIPT   COURSE  SUBJ  AREAS 

RCOURSE 

SI 

FILE.NAME 

FIELD. NAME 

FIELD.DESCRI 

ALTERNATE 

ADMISSIO 

COURSE  ID 

LETTER'GRADE 

SEMESTER 

MAJOR 

NATIONALITY 

SEX 

SOC  SEC  NUM 

STUD  ID" 

STUD'NAME 

COURSE  ID  NUMBER 
FINAL  6RADE  ASSIGNED 
WHEN  TAKEN  <SEM/YEAR) 
AREA  OF  DEGREE 
COUNTRY  OF  ORIGIN 
SEX 

SOCIAL  SECURITY  NO. 
STUDENT  ID 
STUDENT  NAME 

CID 

L6 

WHEN 

MAJ 

RACE 

SEX 

SSN 

SID 

SN 

AVAIL 

COURSE  ID 

COURSE  ID  NUMBER 

CID 

CREDIT'HOURS 

0.0  TO  4.0  COURSE  CREDIT 

CHRS 

EDICTION 

CALLED'EXEC 
EXEC  NAME 
PURPOSE 

NAME  OF  CALLED  EXEC 
NAME  OF  FOCEXEC 
PURPOSE  OF  FOCEXEC 

CE 
EN 
DOES 

FILE  NAME 

FOCUS  MASTER  FILE  DESCRIP 

FLN 

VAR  DESCRIPT 

DESCRIPTION  OF  VARIABLE 

VDES 

VAR'FORMAT 

ALLOWABLE  VARIABLE  FORMAT 

VFMT 

VAR'NAME 

VARIABLES  USED  IN  FOCEXEC 

VN 

FDICTION 

ALTERNATE 

FIELD  DESCRI 

FIELD'FORMAT 

FIELD'NAME 

FIELD'TYPE 

KEY   " 

FILE  DESCRIP 

ALIAS 

INFO  ON  SE6MENT  FIELDS 

TYPE  &  AMOUNT  OF  DATA 

NAME  OF  FIELD 

I  MEANS  INDEXED 

Y  MEANS  KEY  FIELD 

DESCRIPTION  OF  MASTER 

ALT 

FDDE 

FFMT 

FDN 

FDTP 

KEY 

FDES 

FILE'NAME 

NAME  OF  FOCUS  MASTER  FILE 

FLN 

FILE'TYPE 

TYPE  OF  MASTER  FILE 

FTYP 

MAINTAIN  BY 

ACTIVITY  RESPONSIBLE 

FMAN 

NUM  SE6S" 

NUMBER  OF  SE6MENTS 

NS 

CHICD  OF 

PARENT  OF  SE6MENT 

SPAR 

SE6  DESCRIPT 

INFO  ON  MASTER  SE6MENTS 

SDES 

SES'NAME 

NAME  OF  MASTER  SEGMENT 

SE6N 

SEG'TYPE 

SEGMENT  KEY  *  ORDER  INFO 

STYP 

REQ 

COURSE  ID 
SUBJ  AREA 

COURSE  ID  NUMBER 
SUBJECT  AREA  OF  COURSE 

CID 
SA 
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FILE. NAME 

ADMISSIQ 


SE6.NAME 
COURSE 

STUDENT 


FIELD  NAME 


ALTERNATE   KEY   FIELD  TYPE 


AVAIL      DESCRIPT 

EDICTION    CALLED 
EXECS 

FILE  NAM 

VARIABLE 


FDICTION    FIELDS 


REQ 


FILES 


SEGMENTS 


DESCRIPT 


COURSE  ID 

LETTER"6RADE 

SEMESTER 

MAJOR 

NATIONALITY 

SEX 

SOC  SEC  NUM 

STUD  ID" 

STUD'NAME 

COURSE  ID 

CREDIT'HOURS 

CALLED'EXEC 

EXEC  NAME 

PURPOSE 

FILE  NAME 

VAR  DESCRIPT 

VAR'FQRMAT 

VAR'NAME 

ALTERNATE 

FIELD  DESCRI 

FIELD'FORMAT 

FIELD'NAME 

FIELD'TYPE 

KEY   " 

FILE  DESCRIP 

FILE'NAME 

FILE'TYPE 

MAINTAIN  BY 

NUM  SE6S" 

CHICD  OF 

SE6  DESCRIPT 

SE6"NAME 

SE6"TYPE 

COURSE  ID 

SUBJ  AREA 


CID 

L6 

WHEN 

MAJ 

RACE 

SEX 

SSN 

SID 

SN 

CID 

CHRS 

CE 

EN 

DOES 

FLN 

VDES 

VFMT 

VN 

ALT 

FDDE 

FFMT 

FDN 

FDTP 

KEY 

FDES 

FLN 

FTYP 

FMAN 

NS 

SPAR 

SDES 

SE6N 

STYP 

CID 

SA 


EXEC_NAME  PURPOSE 

MAINMENU  DATA  DICTIONARY  CHOICES 

FILEMENU  FOCUS  FILE  INFO  MENU 

EXECMENU  FOCUS  EXECS  INFO  MENU 

MANTMENU  MAINTENANCE  MENU 

MODIEXEC  MODIFY  EXEC  INFO  MENU 

CH6EXEC  UPDATE  EXEC  INFO  MENU 

CHB1EXEC  UPDATES  VARIABLE  INFO 

DELEXEC  DELETE  EXEC  INFO  MENU 

DEL1EXEC  DELETE  INFO  ON  AN  EXEC 

DEL2EXEC  DELETE  INFO  ON  A  VARIABLE 

DEL3EXEC  DELETE  INFO  ON  A  FILE 

DEL4EXEC  DELETE  INFO  ON  EXEC 

ADDEXEC  ADD  EXEC  INFORMATION 

ADD1EXEC  ADD  EXEC  NAMES 

ADD2EXEC  ADD  VARIABLE  INFO 

ADD3EXEC  ADD  MASTER  FILE  INFO 

ADD4EXEC  ADD  CALLED  EXEC  INFO 

CH62EXEC  UPDATES  EXEC  PURPOSE 

PROJMENU  CALLS  PROGRAM  OR  DICTION 

CALCQPR  CALCULATES  QPR  BY  STUDENT 

SUBJSUM  TABLES  GRADES  BY  SUBJ 


118 


EXEC  NAME  VAR  NAME  VAR  FORMAT  VAR  DESCRIPT 


ADOEXEC 

&CHOOSE 

MENU  CHOICE 

CALCQPR 

N6RADE 

F3.1 

LETTER  6RADE  TO  NUN  6RADE 

POINTS 

F6.1 

N6RADE  *  CHRS 

QPR 

F4.1 

POINTS/CHRS 

CHGEXEC 

&CHOICE 

MENU  SELECTION 

ItYESNO 

Y/N  TO  CONTINUE 

EXECMENU 

&CH0ICE 

MENU  CHOICE 

ItOK 

OK  TO  CONTINUE  Y/N 

FILEMENU 

&CHOICE 

MENU  CHOICE 

JtOK 

OK  TO  CONTINUE  Y/N 

MAINMENU 

&SELECT 

/ 

MENU  CHOICE 

MANTMENU 

IcOK 

OK  TO  CONTINUE  Y/N 

It  WHICH 

MENU  CHOICE 

MODIEXEC 

&WHAT 

MENU  CHOICE 

PROJMENU 

&SELECT 

MENU  CHOICE 

EXEC.NAME 

CALLED. EXEC  FILE 

.NAME  FILE.DESCRIP 

ADDEXEC 


ADD1EXEC 
A0D2EXEC 
ADD3EXEC 
ADD4EXEC 
CALCQPR 

CH6EXEC 

CH61EXEC 

DELEXEC 


DEL1EXEC 
DEL2EXEC 
DEL3EXEC 
DEL4EXEC 
EXECMENU 


FILEMENU 

MAINMENU 

MANTMENU 
MODIEXEC 


PROJMENU 
SUBJSUM 


ADD1EXEC 
ADD2EXEC 
ADD3EXEC 
ADD4EXEC 


PROJMENU 

CH61EXEC 

DEL1EXEC 
DEL2EXEC 
DEL3EXEC 
DEL4EXEC 


EXECDESC 

EXECINFO 

SUMEXEC 

FILDESC 

FLDINFO 

SUMFILE 

EXECMENU 

FILEMENU 

MANTMENU 

MODIEXEC 

MODIFILE 

ADDEXEC 

CH6EXEC 

DELEXEC 

PROJMENU 


EDICTION  EXEC  MASTER  DICTIONARY 

EDICTION  EXEC  MASTER  DICTIONARY 

EDICTION  EXEC  MASTER  DICTIONARY 

EDICTION  EXEC  MASTER  DICTIONARY 

ADMISSIO  STUD  AND  COURSES  TAKEN 

AVAIL  CREDIT  HRS  BY  COURSE 

EDICTION  EXEC  MASTER  DICTIONARY 


EDICTION 
EDICTION 
EDICTION 
EDICTION 


EXEC  MASTER  DICTIONARY 

EXEC  MASTER  DICTIONARY 

EXEC  MASTER  DICTIONARY 

EXEC  MASTER  DICTIONARY 


ADMISSIO 
REQ 


STUD  AND  COURSES  TAKEN 
COURSE  SUBJ  AREAS 
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APPENDIX  B 


TRANSCRIPT  SUMMARY  APPLICATION  SOURCE  CODE 


#******#«**t***««****«ft*t**tt«*****#*#*«#t*tt«tt********t**##*##**t* 

MODULE:  PROJMENU  FOCEXEC 

WRITTEN  BY:  BOB  REPP 

CALLED  BY: 

CALLS:  CALCQPR.  SUBJSUM,  MAINMENU  FOCEXEC 

PURPOSE:  MAIN  PROJECT  MENU 

♦♦♦♦•♦ft************************************************************* 

SET  MS6=0FF 

-CRTCLEAR 

-BEGIN 

-CRTCLEAR 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE 

-TYPE   !"""PR03ECT"fiER0 I 

-TYPE   !  

-TYPE   ! 

-TYPE   I       STUDENT  TRANSCRIPT  SUMMARY  <1> 

-TYPE   !       DATA  DICTIONARY  <2> 

-TYPE   !       QUIT  <Q> 

-TYPE   ! 

-TYPE   ! 

-TYPE   I 

-TYPE 

-TYPE 

-TYPE 

-PROMPT  I.SELECT.  WHAT  IS  YOUR  CHOICE?. 

-IF         ^SELECT  EQ  1  60T0  CALCQPR 

ELSE  IF  {(SELECT  EQ  2  60T0  MAINMENU 

ELSE  IF  &SELECT  IS  'Q'  GOTO  EXIT 

ELSE  60T0  BEGIN; 
-CALCQPR 
EXEC  CALCQPR 
-RUN 

EXEC  SUBJSUM 
-RUN 

-CRTCLEAR 
-GOTO  BEGIN 
-MAINMENU 
EXEC  MAINMENU 
-RUN 

-CRTCLEAR 
-60T0  BE6IN 
-EXIT 
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*****  ********************************  ************************  ******* 

MODULE:  CALCQPR  FOCEXEC 

WRITTEN  BY:  BOB  REPP 

CALLED  BY:  PROJMENU  FOCEXEC 

CALLS:  ADMISSIO  FOCUS,  AVAIL  FOCUS 

AVAIL  MASTER.  ADMISSIO  MASTER 

PURPOSE:  JOINS  FILES  AND  CALCULATES  QPR 
H  STUDENT  BASED  ON  ALL  COURSES  TAKEN  EXCEPT  THOSE 
GRADE  OF  MV" 
♦a**************************************************** 


FOR  EAC 
WITH  A 

-CRTCLEAR 
JOIN  CID  IN  ADM 
DEFINE  FILE  ADM 
N6RADE/F3.1=IF 
ELSE  IF  LG  EQ 
ELSE  IF  LG  EQ 
ELSE  IF  LG  EQ 
ELSE  O.O; 


ISSIO  TO  CID  IN  AVAIL  AS  AJOIN 

ISSIQ 

L6  EQ  'A'  THEN  4.0 

'B'  THEN  3.0 

'C  THEN  2.0 

'D'  THEN  1.0 


P0INTS/F6. 1»NGRADE*CHRS; 

END 

TABLE  FILE  ADMISSIO 

SUM  POINTS  NOPRINT  CHRS  NOPRINT 

COMPUTE  QPR/F4.1=P0INTS/CHRS| 

BY  SID  BY  STUD  NAME  BY  SSN  BY  MAJOR 


IF  L6  OMITS 
END 


'VT 


ft********************************************************************* 

*  MODULE:    SUBJSUM   FOCEXEC  * 

*  WRITTEN   BY:    BOB   REPP  * 

*  CALLED   BY:    PROJMENU   FOCEXEC  * 

*  CALLS:ADMISSIO   FOCUS, ADMISSIO   MASTER  * 

*  REQ   FOCUS,    REQ   MASTER  * 

*  PURPOSE:    JOINS   ADMISSIO   AND   REQ   AND   PRINTS  * 

*  THE  NUMBER  OF  COURSES  TAKEN  BY  SUBJECT  AREA  ACROSS  GRADES  * 
#**#****#************#*#**#♦****♦*♦*************«***##»*****#***♦#**** 
JOIN   CID    IN   ADMISSIO   TO   CID    IN   REQ   AS   BJOIN 

TABLE   FILE   ADMISSIO 
FOOTING   CENTER 

"TYPE   QUIT    TO   RETURN   TO   MENU- 
COUNT   CID   ACROSS   LG 
BY   SID   BY   SA 
ON   SID   PAGE-BREAK 
RUN 

TRANSCRIPT    SUMMARY    APPLICATION    OUTPUT 


STUD_ID  STUD_NAME 

840007  ABBOT    LOHN    F 

840019  ABELL    DAVID    SROS 

840024  ABRAMSON    ALAN    J 


SOC    SEC    NUM       MAJOR 


423788586 
512727258 
037367483 


ESE 
SAS 
SPH 


QPR 

3.7 
2.4 
3.0 


STUD  ID   SUBJ  AREA 


LETTER_SRADE 
A       B 


D 


840007 


MATH  C 
MATH~PO 
MATH~PR 
STATS 


0 

1 
1 
0 


1 
0 
0 
0 


0 
0 
0 

1 


0 
0 
0 
0 


0 

0 

1 

0 
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STUD_ID 

SUBJ_AREA 

LETTER 
A 

GRADE 
B 

c 

D 

V 

840019 

CHEM 
MATH  C 
MATH~P0 
PHY  CD 
PHY_UD 

1 
0 
0 
0 

0 

0 
0 
0 
0 
0 

0 

1 
1 

1 

0 

0 
0 
0 
0 

1 

0 
0 
0 
0 
0 

STUD_ID 

SUBJ_AREA 

'letter 

A   ' 

GRADE 
B 

c 

D 

V 

840024 

A  M  ENG 
ECECT  E 
MATH  PR 
OPHYSCI 
OTH  ENG 

0 
0 
0 
0 
0 

0 

0 
0 
0 
0 
0 

0 
0 
0 
0 
0 

0 

0 

1 

0 
0 
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